lkml.org 
[lkml]   [2007]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 05/11] syslets: core code
    On Thu, Feb 15, 2007 at 09:05:13AM -0800, Davide Libenzi (davidel@xmailserver.org) wrote:
    > On Thu, 15 Feb 2007, Linus Torvalds wrote:
    >
    > > I don't think the "atom" approach is bad per se. I think it could be fine
    > > to have some state information in user space. It's just that I think
    > > complex interfaces that people largely won't even use is a big mistake. We
    > > should concentrate on usability first, and some excessive cleverness
    > > really isn't a big advantage.
    > >
    > > Being able to do a "open + stat" looks like a fine thing. But I doubt
    > > you'll see a lot of other combinations.
    >
    > I actually think that building chains of syscalls bring you back to a
    > multithreaded solution. Why? Because suddendly the service thread become
    > from servicing a syscall (with possible cachehit optimization), to
    > servicing a whole session. So the number of service threads needed (locked
    > down by a chain) becomes big because requests goes from being short-lived
    > syscalls to long-lived chains of them. Think about the trivial web server,
    > and think about a chain that does open->fstat->sendhdrs->sendfile after an
    > accept. What's the difference with a multithreaded solution that does
    > accept->clone and execute the above code in the new thread? Nada, NIL.

    That is more ideological question about micro-thread design at all.
    If syslet will be able to perform only one syscall, one will have 4
    threads for above case, not one, so it is even more broken.

    So, if Linux moves that way of doing AIO (IMO incorrect, I think that
    the correct state machine made not of syscalls, but specially crafted
    entries - like populate pages into VFS, send chunk, recv chunk without
    blocking and continue on completion and the like), syslets with attached
    state machines are the (smallest evil) best choice.

    > Actually, there is a difference. The standard multithreaded function is
    > easier to code in C than with the complex atoms chains. The number of
    > service thread becomes suddendly proportional to the number of active
    > sessions.
    > The more I look at this, the more I think that async_submit should submit
    > simple syscalls, or an array of them (unrelated/parallel).

    That is the case - atom items (I do hope that this subsystem would be
    able to perform not only syscalls, but any kernel interfaces suitable
    prototypes, v2 seems to move that direction) are called asynchronously
    from main userspace thread to achieve the maximum performance.

    > - Davide
    >

    --
    Evgeniy Polyakov
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-02-15 18:25    [W:4.128 / U:0.744 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site