Re: fwd: Scheduler activations (IIRC) question

Hi Dan!  It's nice to see the Big Names In Scalability dropping by :)

Dan Kegel wrote:
> Jamie Lokier is heading down the KSE / kernel activations
> pathway because he still thinks kernel threads are wrong.

Kernel threads are not wrong in fact I am using them!

> The discussion is under the subject "Scheduler activations (IIRC) question":
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=106098891019055&w=2
> "It isn't reasonable to make a kernel thread per userspace state
> machine: I want less preemption than that implies, having more control
> over locking contexts between the state machines than that.  And each
> kernel thread uses a relatively large space, while the states are
> quite small and it is reasonable to have a large number."
> 
> Maybe someone familiar with NPTL (or the drawbacks in NGPT) can straighten 
> him out there? I guess it'd be just as good to let him try to implement
> scheduler activations with futexes.  [...]

You're assuming that I am trying to do userspace threads.  Not so.

I'm doing the same thing that folks who use epoll() are doing: lots of
state machines, few stacks.  Not all my state machines are I/O
related; some of them are more like scheduled objects in a game or
network stack.

Now, perhaps it makes more sense to strictly separate different
classes of state machine, let them do their thing, and create threads
for the ones that want to do a system call or so.

There, we can use NPTL and be happy.

But that's more or less what I've brought up, with a little shuffling
of which thread is running what, isn't it? :)

> It'd be a fun show.

If someone wants to pay for the entertainment I'll be pleased ;)

> http://marc.theaimsgroup.com/?l=linux-kernel&m=106110360515245&w=2
> "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."
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=106114511505661&w=2
> "Plus AIO link(), unlink(), rename(), open() (especially open),
> msync(), mlock(), mmap(), sendfile(), readdir(), readlink(), ioctl()
> and a few more."
> 
> Maybe someone familiar with the state of AIO could comment?

I'll be very pleased if AIO does the trick.

On the bright side, a kernel-side form of what I brought up, without
the userspace kludges (i.e. nothing special in userspace), is one way
to extend AIO to all the blocking operations: allocate extra kernel
stacks on demand, to contain the state for blocking operations which
are too difficult to implement as kernel state machines, e.g., AIO open().

Worth the thought?

-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to [email protected].  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"[email protected]">[email protected]</a>