About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Thu, 01 Feb 2007

Generic AIO by scheduling stacks by Zach Brown.


Zach Brown has announced his AIO patchset which works as multistack - i.e. each process has set of AIO related stacks (read: it has set of functions blocked in syscalls), which then are switched by scheduler in kernelspace.

This idea is exactly how M:N therading library works but in kernelspace. Another difference is that there is only one scheduler, but in M:N threading library userspace needs to have its own.
A you may noticed, userspace M:N threading works faster in all aspects than kernelspace scheduling/creation, so likely Zach's approach, although there are some nitpicks - it uses too much calls to schedule() to make my something-needs-clarification counter low. Exactly the same problem exists in NTL - it needs rescheduling for start, so I'm implementing better context switching methods similar to setcontext() calls. Another caveat is per-syscall allocation of the new structure, likely it can be worked out by having cache of allocated, but unused ones.
So, number of rescheduling and per-syscall allocations scare me in that approach.

AS ingo Molnar noted "all these LWP, fibre, firbril, micro-thread or N:M concepts fit? Most of the time they are just a /weakening/ of the [the most easy to program one] concept".
And he is right, state machine must be used to achieve the maximum peroformance, that is what I apln to put into M:N threading library, which will just replace blocked syscalls with kevent-driven requests, which in turn form some kind of a state machine, which, by the help of the library, will be removed from higher userspace layer, so programmer would never knew about it.
Although he is not right that kernel->user context switch is a way about user->user times, at least with thread creation/allocation (which is some way is used in this AIO model) its price is about 2-20 times slower, so it is not acceptible to have such latency.

Another couple of words for my work - kevent AIO, which only works for aio_sendfile() right now, was designed in the state machine way - there are several execution threads indeed, but each request is actually a set of smaller ones, which are executed one-by-one in completion of previous one. Since completion happens in different contexts, special machine is designed. It works similar to Tux state machine though, but its tasks so far only included pages reading into VFS cache and theirs sending.

Shit, I would say, that kevent based AIO works that way (and can be even better with network AIO), but 1. i'm not subscribed to linux-kernel@, and 2. I'm modest enough to only say how cool I am in my blog :)

/devel/threading :: Link / Comments ()