In message <1071706550.561399.5461.nullmailer@yamt.dyndns.org>,
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.