On Sat, 3 Feb 2007, Ingo Molnar wrote:
>
> Well, in my picture, 'only if you block' is a pure thread utilization
> decision: bounce a piece of work to another thread if this thread cannot
> complete it. (if the kernel is lucky enough that the user context told
> it "it's fine to do that".)
Sure, you can do it that way too. But at that point, your argument that we
shouldn't do it with fibrils is wrong: you'd still need basically the
exact same setup that Zach does in his fibril stuff, and the exact same
hook in the scheduler, testing the exact same value ("do we have a pending
queue of work").
So at that point, you really are arguing about a rather small detail in
the implementation, I think.
Which is fair enough.
But I actually think the *bigger* argument and problems are elsewhere,
namely in the interface details. Notably, I think the *real* issues end up
how we handle synchronization, and how we handle signalling. Those are in
many ways (I think) more important than whether we actually can schedule
these trivial things on multiple CPU's concurrently or not.
For example, I think serialization is potentially a much more expensive
issue. Could we, for example, allow users to serialize with these things
*without* having to go through the expense of doing a system call? Again,
I'm thinking of the case of no IO happening, in which case there also
won't be any actual threading taking place, in which case it's a total
waste of time to do a system call at all.
And trying to do that actually has implications for the interfaces (like
possibly returning a zero cookie for the async() system call if it was
doable totally synchronously?)
Signal handling is similar: I actually think that a "async()" system call
should be interruptible within the context of the caller, since we would
want to *try* to execute it synchronously. That automatically means that
we have semantic meaning for fibrils and signal handling.
Finally, can we actually get POSIX aio semantics with this? Can we
implement the current aio_xyzzy() system calls using this same feature?
And most importantly - does it perform well enough that we really can do
that?
THOSE are to me bigger questions than what happens inside the kernel, and
whether we actually end up using another thread if we end up doing it
non-synchronously.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
