Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

[Zach Brown <zach.brown@oracle.com>]

I'm finally back from my travel and conference hiatus.. you guys have  
been busy! :)

On Feb 13, 2007, at 6:20 AM, Ingo Molnar wrote:

> I'm pleased to announce the first release of the "Syslet" kernel  
> feature
> and kernel subsystem, which provides generic asynchrous system call
> support:
>
>    http://redhat.com/~mingo/syslet-patches/

In general, I really like the look of this.

I think I'm convinced that your strong preference to do this with  
full kernel threads (1:1 task_struct -> thread_info/stack  
relationship) is the right thing to do.  The fibrils fell on the side  
of risking bugs by sharing task_structs amongst stacks executing  
kernel paths.  This, correct me if I'm wrong, falls on the side of  
risking behavioural quirks stemming from task_struct references that  
we happen to have not enabled sharing of yet.

I have strong hopes that we won't actually *care* about the  
behavioural differences we get from having individual task structs  
(which share the important things!) between syscall handlers.  The  
*only* seemingly significant case I've managed to find, the IO  
scheduler priority and context fields, is easy enough to fix up.   
Jens and I have been talking about that.  It's been bugging him for  
other reasons.

So, thanks, nice work.  I'm going to focus on finding out if its  
feasible for The Database to use this instead of the current iocb  
mechanics.  I'm optimistic.

> Syslets are small, simple, lightweight programs (consisting of
> system-calls, 'atoms')

I will admit, though, that I'm not at all convinced that we need  
this.  Adding a system call for addition (just addition?  how far do  
we go?!) sure feels like a warning sign to me that we're heading down  
a slippery slope.  I would rather we started with an obviously  
minimal syscall which just takes an array of calls and args and  
executes them unconditionally.

But its existance doesn't stop the use case I care about.  So it's  
hard to get *too* worked up about it.

> Comments, suggestions, reports are welcome!

For what it's worth, it looks like 'x86-optimized-copy_uatom.patch'  
got some hunks that should have been in 'x86-optimized- 
sys_umem_add.patch'.

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