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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 [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]
  Powered by Linux