On Thu, Feb 15, 2007 at 09:39:33AM -0800, Davide Libenzi ([email protected]) wrote:
> On Thu, 15 Feb 2007, Evgeniy Polyakov wrote:
>
> > On Thu, Feb 15, 2007 at 09:05:13AM -0800, Davide Libenzi ([email protected]) wrote:
> > >
> > > 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.
>
> Nope, just one thread. Well, two, if you consider the "main" dispatch
> thread, and the syscall service thread.
Argh, if they are supposed to run synchronously, for example stat can be
done in parallel with sendfile in above example, but generally yes, one
execution thread.
> > 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.
>
> But at that point you don't need to have complex atom interfaces, with
> chains, whips and leather pants :) Just code it in C and submit that to
> the async engine. The longer is the chain though, the closer you get to a
> fully multithreaded solution, in terms of service thread consuption. And
> what do you save WRT a multithreaded solution? Not thread
> creation/destroy, because that cost is fully amortized inside the chain
> execution cost (plus a pool would even save that).
> IMO the plus of a generic async engine is mostly from a kernel code
> maintainance POV. You don't need anymore to have AIO-aware code paths,
> that automatically transalte to smaller and more maintainable code.
It is completely possible to not wire up several syscalls and just use
only one per async call, but _if_ such a requirement rises, the whole
infrastructure is there.
> - Davide
>
--
Evgeniy Polyakov
-
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]
