On Tue, May 13, 2008 at 04:42:07PM +0200, Ingo Molnar wrote:
That might be the case for some users, but it isn't the case for XFS.
The first thing that each task does is grab a spinlock, so if you put as
much in flight as early as possible, you end up with horrible contention
on that spinlock. I have no idea whether this is the common case for
multi-valued semaphores or not, it's just the only one I have data for.
I think the completion code is less optimised than the semaphore code
today. Clearly the same question does arise, but I don't know what the
answer is for completion users either.
Let's do a quick survey. drivers/net has 5 users:
3c527.c -- execution_cmd has a mutex held, so never more than one task
waiting anyway. xceiver_cmd is called during open and close which I think
are serialised at a higher level. In any case, no performance issue here.
iseries_veth.c -- grabs a spinlock soon after being woken.
plip.c -- called in close, no perf implication.
ppp_synctty.c -- called in close, no perf implication.
ps3_gelic_wireless.c - If this isn't serialised, it's buggy.
Maybe drivers/net is a bad example. Let's look at */*.c:
as-iosched.c -- in exit path.
blk-barrier.c -- completion on stack, so only one waiter.
blk-exec.c -- ditto
cfq-iosched.c -- in exit path
crypto/api.c -- in init path
crypto/gcm.c -- in setkey path
crypto/tcrypt.c -- crypto testing. Not a perf path.
fs/exec.c -- waiting for coredumps.
kernel/exit.c -- likewise
kernel/fork.c -- completion on stack
kernel/kmod.c -- completion on stack
kernel/kthread.c -- kthread creation and deletion. Shouldn't be a hot
path, plus this looks like there's only going to be one task waiting.
kernel/rcupdate.c -- one completion on stack, one synchronised by a mutex
kernel/rcutorture.c -- doesn't matter
kernel/sched.c -- both completions on stack
kernel/stop_machine.c -- completion on stack
kernel/sysctl.c -- completion on stack
kernel/workqueue.c -- completion on stack
lib/klist.c -- This one seems like it could potentially have lots of
waiters, if only anything actually used klists.
It seems like most users use completions where it'd be just as easy
to use a task pointer and call wake_up_task(). In any case, I think
there's no evidence one way or the other about how people are using
multi-sleeper completions.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
