Subject: Re: curproc removal (NFS, ...)
To: Jonathan Stone <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 05/25/2004 17:34:50
Content-Type: text/plain; charset=US-ASCII; format=flowed
On May 25, 2004, at 5:25 PM, Jonathan Stone wrote:
> In message <E1BSlfifirstname.lastname@example.org>Jonathan Stone
>>> (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
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
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 <email@example.com>
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----