lkml.org 
[lkml]   [2007]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support
Date

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/

\
 
 \ /
  Last update: 2007-02-15 03:47    [W:1.816 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site