Messages in this thread | | | Date | Sun, 17 Aug 2003 10:34:55 +0200 | From | Mike Galbraith <> | Subject | Re: Scheduler activations (IIRC) question |
| |
At 07:55 AM 8/17/2003 +0100, Jamie Lokier wrote: >Mike Galbraith wrote: > > >The point of the mechanism is to submit system calls in an > > >asynchronous fashion, after all. A proper task scheduling is > > >inappropriate when all we'd like to do is initiate the syscall and > > >continue processing, just as if it were an async I/O request. > > > > Ok, so you'd want a class where you could register an "exception handler" > > prior to submitting a system call, and any subsequent schedule would be > > treated as an exception? (they'd have to be nestable exceptions too > > right?... <imagines stack explosions> egad:) > >Well, apart from not resembling exceptions, and no they don't nest :)
(ok, I only misunderstood _almost_ everything:)
>You may be wondering what happens when I do five stat() calls, all of >which should be asynchronous (topical: to get the best out of the >elevator). > >Nested? Not quite. At each stat() call that blocks for I/O, its >shadow task becomes active; that creates its own shadow task (pulling >a kernel task from userspace's cache of them), then continues to >perform the next item of work, which is the next stat(). > >The result is five kernel threads, each blocked on I/O inside a stat() >call, exactly as desired. A sixth kernel thread, the only one running >of my program, is continuing the work of the program.
Oh. You just want to dispatch N syscalls from one entry to the kernel?
>Soon, each of the I/O bound threads unblocks, returns to userspace, >stores its result, queues the next work of this state machine, adds >this kernel task to userspace's cache, and goes to sleep. > >As you can see, this achieves asynchronous system calls which are too >complex for aio(*), best use of the I/O elevator, and 100% CPU >utilisation doing useful calculations. > >Other user/kernel scheduler couplings are possible, but what I'm >describing doesn't ask for much(**). Just the right behaviour from >the kernel's scheduling heuristic: namely, waker not preempted by >wakee. Seems to be the way it's going anyway.
If that's all you need, a SCHED_NOPREEMPT (synchronous wakeups) class should do the trick. I thought you wanted a huge truckload more than that.
-Mike
- 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/
| |