[lkml]   [2007]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 06/11] syslets: core, documentation
On Wed, 14 Feb 2007, Benjamin LaHaise wrote:

> On Wed, Feb 14, 2007 at 09:52:20AM -0800, Davide Libenzi wrote:
> > That'd be, instead of passing a chain of atoms, with the kernel
> > interpreting conditions, and parameter lists, etc..., we let gcc
> > do this stuff for us, and we pass the "clet" :) pointer to sys_async_exec,
> > that exec the above under the same schedule-trapped environment, but in
> > userspace. We setup a special userspace ad-hoc frame (ala signal), and we
> > trap underneath task schedule attempt in the same way we do now.
> > We setup the frame and when we return from sys_async_exec, we basically
> > enter the "clet", that will return to a ret_from_async, that will return
> > to userspace. Or, maybe we can support both. A simple single-syscall exec
> > in the way we do now, and a clet way for the ones that requires chains and
> > conditions. Hmmm?
> Which is just the same as using threads. My argument is that once you
> look at all the details involved, what you end up arriving at is the
> creation of threads. Threads are relatively cheap, it's just that the
> hardware currently has several performance bugs with them on x86 (and more
> on x86-64 with the MSR fiddling that hits the hot path). Architectures
> like powerpc are not going to benefit anywhere near as much from this
> exercise, as the state involved is processed much more sanely. IA64 as
> usual is simply doomed by way of having too many registers to switch.

Sort of, except that the whole thing can complete syncronously w/out
context switches. The real point of the whole fibrils/syslets solution is
that kind of optimization. The solution is as good as it is now, for
single syscalls (modulo sys_async_cancel implementation), but for multiple
chained submission it kinda stinks IMHO. Once you have to build chains,
and conditions, and new syscalls to implement userspace variable
increments, and so on..., at that point it's better to have the chain to
be coded in C ala thread proc. Yes, it requires a frame setup and another
entry to the kernel, but IMO that will be amortized in the cost of the
multiple syscalls inside the "clet".

- Davide

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-14 20:49    [W:0.178 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site