Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

Ingo Molnar
2007-02-28T09:52:48Z

* Davide Libenzi <davidel@xmailserver.org> wrote:

> > my current thinking is that special-purpose (non-programmable,
> > static) APIs like aio_*() and lio_*(), where every last cycle of
> > performance matters, should be implemented using syslets - even if
> > it is quite tricky to write syslets (which they no doubt are - just
> > compare the size of syslet-test.c to threadlet-test.c). So i'd move
> > syslets into the same category as raw syscalls: pieces of the raw
> > infrastructure between the kernel and glibc, not an exposed API to
> > apps. [and even if we keep them in that category they still need
> > quite a bit of API work, to clean up the 32/64-bit issues, etc.]
>
> Why can't aio_* be implemented with *simple* (or parallel/unrelated)
> syscall submit w/out the burden of a complex, limiting and heavy API

there are so many variants of what people think 'asynchronous IO' should
look like - i'd not like to limit them. I agree that once a particular
syslet script becomes really popular, it might (and should) in fact be
pushed into a separate system call.

But i also agree that a one-shot-syscall sys_async() syscall could be
done too - for those uses where only a single system call is needed and
where the fetching of a single uatom would be small but nevertheless
unnecessary overhead. A one-shot async syscall needs to get /8/
parameters (the syscall nr is the seventh parameter and the return code
of the nested syscall is the eighth). So at least two parameters will
have to be passed in indirectly and validated, and 32/64-bit compat
conversions added, etc. anyway!

The copy_uatom() assembly code i did is really fast so i doubt there
would be much measurable performance difference between the two
solutions. Plus, putting the uatom into user memory allows the caching
of uatoms - further dilluting the advantage of passing in the values per
register. The whole difference should be on the order of 10 cycles, so
this really isnt a high prio item in my view.

> Now that chains of syscalls can be way more easily handled with
> clets^wthreadlets, why would we need the whole syslets crud inside?

no, threadlets dont really solve the basic issue of people wanting to
'combine' syscalls, avoid the syscall entry overhead (even if that is
small), and the desire to rely on kthread->kthread context switching
which is even faster than uthread->uthread context-switching, etc.
Furthermore, syslets dont really cause any new problem. They are almost
totally orthogonal, isolated, and cause no wide infrastructure needs.

as long as syslets remain a syscall-level API, for the measured use of
the likes of glibc and libaio (and not exposed in a programmable manner
to user-space), i see no big problem with them at all. They can also be
used without them having any classic pthread user-state (without linking
to libpthread). Think of it like the raw use of clone(): possible and
useful in some cases, but not something that a typical application would
do. This is a 'raw syscall plugins' thing, to be used by those
user-space entities that use raw syscalls: infrastructure libraries. Raw
syscalls themselves are tied to the platform, are not easily used in
some cases, thus almost no application uses them directly, but uses the
generic functions glibc exposes.

in the long run, sys_syslet_exec(), were it not to establish itself as a
widely used interface, could be implemented purely from user-space too
(say from the VDSO, at much worse performance, but the kernel would stay
backwards compatible with the syscall), so there's almost no risk here.
You dont like it => dont use it. Meanwhile, i'll happily take any
suggestion to make the syslet API more digestable.

Ingo