Subject: Re: SMP re-entrancy in kernel drivers/"bottom half?"
To: YAMAMOTO Takashi <email@example.com>
From: Jonathan Stone <firstname.lastname@example.org>
Date: 12/17/2003 16:27:39
In message <email@example.com>,
YAMAMOTO Takashi writes:
>it sounds like a regression.
At the moment excluding special cases like TLB shutdown, only one CPU
can be in the kernel at a time. this is a BIG performance limit for
the kinds of workloads I run.
I've sketched a scheme that allows multiple CPUs in the `bottom half'
of the kernel, in addtion to one CPU coming from uerspace (or running
softint callouts) .
I dont see how that can possibly count as a "regression", specially
not for the kinds of workload I described earlier.
>what's "higher levels"?
See spl(9). roughly, splvm() through splhigh(). Or pick your own point
above splnet(), and define everything from there to splhigh() as grabbing
a spinlock. Me, agnostic about spltty(), splstatclock(), and splclock(),
but I suppose someone wanting more interrupt-service bandwidth for lots
of serial devices might want SMP-safe serial interrupts.
>how low level interrupt handlers (e.g. Xintr_* on i386) raise SPL?
Last I looked, they use atomic instructions to modify a flags word.
But changing one or two routines is a heck of a lot simpler than
adding lock() calls to every data structure or subsystem.
And I really, *really* want more than one CPU's bandwidth for kernel
tasks like servicing NIC interrupts and running the network stack.