Subject: Re: SMP re-eetrancy in "bottom half" drivers
To: Jonathan Stone <firstname.lastname@example.org>
From: Stephan Uphoff <email@example.com>
Date: 05/17/2005 22:00:26
On Tue, 2005-05-17 at 19:21, Jonathan Stone wrote:
> In message <1116370425.7597.824.camel@palm>,
> Stephan Uphoff writes:
> >No need to.
> >We both agree on the cost of context switches and talked to some of the
> >same people. This being said there is no need to change the MMU for an
> >interrupt thread (the kernel is always mapped on x86 - gentle
> >clue-by-four as requested) but FreeBSD's context switch is not as light
> >as it could be.
> I haven't looked in a few months; but last time I did look, I asked
> Nathan Williams, and Nathan confirmed the i386 code was thwacking the
> CR-whatever register rather more than we needed to (possibly for
> kernel-only to kernel-only cases?) I think that's been addressed; tho'
> obviously I need to check in detail if I'm going to work in this
Yamamoto-san not only fixed this (for i386) but went on to delay context
switches wherever possible. This allows even a normal thread to run with
a borrowed MMU context as long as it runs in the kernel and does not
copyin/out data to userspace (and a few other things)
This is on my list of the things to steal for FreeBSD.
> I'm thinking of ancient history, so I may well be misremembering. But
> as I recall, when this last came up, circa Jan 2004, there was some
> opposition to introducing a strict hierarchy of SPLs and locks. OTOH,
> for one, Jason just said he's no longer opposed. I don't recall
> who else was strongly against the idea.
> My own grip of the NetBSD's current locking protocol for the biglock
> vs. scheduler locks, lacks opposable thumbs. But (though I may be
> hopelessly out-of-date), I could easily see that needing some re-work,
> to fit into the kind of strict deadlock-free hierarchy Bill and I (and
> others?) are talking about.
> Personally, I'd sooner see some progress on making some MI drivers
> SMP-safe, so that there's something to measure, whereby different
> SPL/lock hierarchies and implementations (or other completely
> different schemes) can be compared and evaluated.
> Right now we're in a vacuum. Unless we start somewhere, we'll
> never get out of that vacuum....
I know that I cursed a lot when I had to do something that required
keeping spl and locks in sync :-). However this has been some time ago
and I have to do some source reading before I can form an opinion about
the current code.