In message <1117738588.27369.5587.camel@palm>,
Stephan Uphoff writes:

>Mhhh - not all locks need to be strongly ordered.
>Maybe we can do the same for spl levels?


Sure, we can do that, if someone does the leg-work to examine all
possible dynamic call-graphs, and thereby figure out which locks need
to be ordered, and which are safe to not order.  And then documents
the partial ordering.

I view totally-ordered locks as a way to avoid or defer that work
(or, if you will, a partial ordering of locks is an optimization).


>> Now that leaves me confused! I thought what Bill outlines is, in
>> essence, what I proposed in late 2003. Yamamoto-san, do they sound
>> like the same thing to you? Do we have a consensus for it (or for one
>> or other, if they are different)?
>
>Global as in contrast to per CPU?
>I think we all agree that we want per CPU. Right?

I'm not sure I follow you here. The locks which correspond to existing
SPL levels have to be global to ensure synchronization. OTOH, the
other side of the idea (from Yamamoto-san's patch from December 1993)
is to add a flag marking SMP-safe drivers as being SMP-safe, with a
lock in each driver softc.  The kernel can then take interrupts on
each device instance (of an SMP-safe driver) independently of the big
lock, and thus independently of interrupts in other CPUs.

So interrupt-handling can be per CPU (really, per device instance: if
you have more CPUs than SMP-safe drivers, the extra CPUs cant help
interrupts).  Whereas raising SPLs will acquire a (global) lock.

Obviously, one then wants SMP-safe drivers to avoid explicitly raising
SPL. Yamamoto-san's patch did that by adding explicit locks protecting
network-input queues, and using those locks in place of spl[hard]net().
(sic, to avoid any confusion given the different naming in FreeBSD-4).



>Do you have a link handy to your 2003 proposal? 


Not handy.  I think it didn't really go into any more detail than the
last two or three mesages from Bill and myself. (Possibly not even that much).