* Linus Torvalds <[email protected]> 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 [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]
