Subject: Re: curproc removal (NFS, ...)
To: Jason Thorpe <email@example.com>
From: Jonathan Stone <firstname.lastname@example.org>
Date: 05/25/2004 17:25:30
In message <E1BSlfiemail@example.com>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. 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, 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.
Besides, once you get the continuation-passing framework right, most
programmers don't need to mess with it. See opencrypto(9) for one example.