Re: [patch 05/11] syslets: core code

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Or how would you do the trivial example loop that I explained was a 
> good idea:
> 
>         struct one_entry *prev = NULL;
>         struct dirent *de;
> 
>         while ((de = readdir(dir)) != NULL) {
>                 struct one_entry *entry = malloc(..);
> 
>                 /* Add it to the list, fill in the name */
>                 entry->next = prev;
>                 prev = entry;
>                 strcpy(entry->name, de->d_name);
> 
>                 /* Do the stat lookup async */
>                 async_stat(de->d_name, &entry->stat_buf);
>         }
>         wait_for_async();
>         .. Ta-daa! All done ..

i think you are banging on open doors. That async_stat() call is very 
much what i'd like to see glibc to provide, not really the raw syslet 
interface. Nor do i want to see raw syscalls exposed to applications. 
Plus the single-atom thing is what i think will be used mostly 
initially, so all my optimizations went into that case.

while i agree with you that state machines are hard, it's all a function 
of where the concentration of processing is. If most of the application 
complexity happens in user-space, then the logic should live there. But 
for infrastructure things (like the async_stat() calls, or aio_read(), 
or other, future interfaces) i wouldnt mind at all if they were 
implemented using syslets. Likewise, if someone wants to implement the 
hottest accept loop in Apache or Samba via syslets, keeping them from 
wasting time on writing in-kernel webservers (oops, did i really say 
that?), it can be done. If a JVM wants to use syslets, sure - it's an 
abstraction machine anyway so application programmers are not exposed to 
it.

syslets are just a realization that /if/ the thing we want to do is 
mostly on the kernel side, then we might as well put the logic to the 
kernel side. It's more of a 'compound interface builder' than the place 
for real program logic. It makes our interfaces usable more flexibly, 
and it allows the kernel to provide 'atomic' APIs, instead of having to 
provide the most common compounded uses as well.

and note that if you actually try to do an async_stat() sanely, you do 
get quite close to the point of having syslets. You get basically up to 
a one-shot atom concept and 90% of what i have in kernel/async.c. The 
remaining 10% of further execution control is easy and still it opens up 
these new things that were not possible before: compounding, vectoring, 
simple program logic, etc.

The 'cost' of syslets is mostly the atom->next pointer in essence. The 
whole async infrastructure only takes up 20 nsecs more in the cached 
case. (but with some crazier hacks i got the one-shot atom overhead 
[compared to a simple synchronous null syscall] to below 10 nsecs, so 
there's room in there for further optimizations. Our current null 
syscall latency is around ~150 nsecs.)

	Ingo
-
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/