[lkml]   [2007]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling
    On Fri, Feb 02, 2007 at 04:56:22PM -0800, Linus Torvalds wrote:
    > 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?)

    This would be useful - the application wouldn't have to set up state
    to remember for handling completions for operations that complete synchronously
    I know Samba folks would like that.

    The laio_syscall implementation (Lazy asynchronous IO) seems to have
    experimented with such an interface


    > 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, send a message with 'unsubscribe linux-aio' in
    > the body to For more info on Linux AIO,
    > see:
    > Don't email: <a href=mailto:""></a>

    Suparna Bhattacharya (
    Linux Technology Center
    IBM Software Lab, India

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-02-03 08:13    [W:0.024 / U:16.120 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site