Re: [patch 06/11] syslets: core, documentation

[Davide Libenzi]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/