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

Ingo Molnar
2007-02-28T22:29:09Z

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

> On Wed, 28 Feb 2007, Ingo Molnar wrote:
>
> > * Davide Libenzi <davidel@xmailserver.org> wrote:
> >
> > > Did you hide all the complexity of the userspace atom decoding inside
> > > another function? :)
> >
> > no, i made the 64-bit and 32-bit structures layout-compatible. This
> > makes the 32-bit structure as large as the 64-bit ones, but that's not a
> > big issue, compared to the simplifications it brings.
>
> Do you have a new version to review?

yep, i've just released -v5.

> How about this, with async_wait returning asynid's back to a userspace
> ring buffer?
>
> struct syslet_utaom {
> long *result;
> unsigned long asynid;
> unsigned long nr_sysc;
> unsigned long params[8];
> };

we talked about the parameters at length: if they are pointers the
layout is significantly more flexible and more capable. It's a pretty
similar argument to the return-pointer thing. For example take a look at
how the IO syslet atoms in Jens' FIO engine share the same fd. Even if
there's 20000 of them. And they are fully cacheable in constructed
state. The same goes for the webserving examples i've got in the
async-test userspace sample code. I can pick up a cached request and
only update req->fd, i dont have to reinit the atoms at all. It stays
nicely in the cache, is not re-dirtied, etc.

furthermore, having the parameters as pointers is also an optimization:
look at the copy_uatom() x86 assembly code i did - it can do a simple
jump out of the parameter fetching code. I actually tried /both/ of
these variants in assembly (as i mentioned it in a previous reply, in
the v1 thread) and the speed difference between a pointer and
non-pointer variant was negligible. (even with 6 parameters filled in)

but yes ... another two more small changes and your layout will be
awfully similar to the current uatom layout =B-)

> My problem with the syslets in their current form is, do we have a
> real use for them that justify the extra complexity inside the kernel?

i call bullshit. really. I have just gone out and wasted some time
cutting & pasting all the syslet engine code: it is 153 lines total,
plus 51 lines of comments. The total patchset in comparison is:

35 files changed, 1890 insertions(+), 71 deletions(-)

(and this over-estimates it because if this got removed then we'd still
have to add an async execution syscall.) And the code is pretty compact
and self-contained. Threadlets share much of the infrastructure with
syslets: for example the completion ring code is _100%_ shared, the
async execution code is 98% shared.

You are free to not like it though, and i'm willing to change any aspect
of the API to make it more intuitive and more useful, but calling it
'complexity' at this point is just handwaving. And believe it or not, a
good number of people actually find syslets pretty cool.

> Or with a simple/parellel async submission, coupled with threadlets,
> we can cover a pretty broad range of real life use cases?

sure, if we debate its virtualization driven market penetration via self
promoting technologies that also drive customer satisfaction, then we'll
be able to increase shareholder value by improving the user experience
and we'll also succeed in turning this vision into a supply/demand
marketplace. Or not?

Ingo