--Apple-Mail-87--149692064
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


On May 25, 2004, at 5:25 PM, Jonathan Stone wrote:

> In message <E1BSlfi-0003ch-00@smeg.dsg.stanford.edu>Jonathan Stone 
> writes
>
>>> (2) When they have fine-grained locking there, they may block
>>> (lockmgr() locks sleep).
>
> Example #1: imagine we have SMP-safe reeentrant network drivers (a la
> the patch postd here a few months ago.) Imagine the rest of the kernel
> is also fine-grained SMP.
>
> We're darn well *not* going to be using a sleeplock to synchronize
> accesses to the per-protocol input queues: the sleep/wakeup penalty is
> bigger than the operation being protected.  We'll use spinlocks
> instead.

Sure, I get that.  Not just spinlocks, but "interrupt knowledgeable 
spinlocks", similar to the mutexes Solaris has (which can either be 
adaptive spin/sleep, or initialized with an interrupt level, at which 
point they are spin only and also perform the equivalent spl operation 
automagically).

My point is that if you use these types of interrupt-mutexes 
everywhere, without actually needing to do that, then you have a 
consequence -- potentially blocking interrupts where it is not 
necessary to do so.

Put another way, if you make it possible to access things in this "no 
thread context kcont environment", you are potentially adding extra 
overhead (in the form of "interrupts blocked when not necessary 
before") in some cases.

>   Follow the same logic up the rest of the network-stack.
> PF_unix aside, I think the only place you really want to sleep is
> between the top of the socket layer and actual process I/O.

Sure, but that's where sosend() is situated!

> Sure, locking (say) multiple TCP hash-tables, to parallelize and
> spread hash lookups amongst multiple CPUs, gets hairier.  But I
> successfully implemented sendfile() and splice() on OSF1/DU/Tru64,
> using a framework very similar to kcont. I dont think it gets any
> hairier than that.

Now, I'm not saying that things currently protected by splsoftnet() 
should not be protected by an interrupt-mutex initialized with 
IPL_SOFTNET... in fact, that is appropriate.  But it's all those things 
that *aren't* currently protected by splsoftnet() that may need to be 
in a kcont environment that I'm concerned about.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>


--Apple-Mail-87--149692064
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAs+YqOpVKkaBm8XkRAl2qAKCNPV1VWIMeUJ8aqpbwrCFDkQqHPgCgqyCw
S/YGnS58Lf0fKz8q74RQZF4=
=SUKn
-----END PGP SIGNATURE-----

--Apple-Mail-87--149692064--