Messages in this thread | | | Subject | Re: [Ksummit-2008-discuss] Delayed interrupt work, thread pools | From | Benjamin Herrenschmidt <> | Date | Thu, 03 Jul 2008 07:00:09 +1000 |
| |
> If you really need the full scheduling capabilities of threads, then it > sounds like a threadpool is all you need (and we should just provide a > unified interface).
That's my thinking nowadays.
> Initially you were implying you'd prefer some type of non blockable > workqueue (i.e. a workqueue that shifts to the next work item when and > earlier item blocks).
That's also something I had in mind, I was tossing ideas around and collecting feedback :-)
> I can see this construct being useful because it > would have easier to use semantics and be more lightweight than a full > thread spawn. It strikes me we could use some of the syslets work to do > this ...
Precisely what I had in mind.
> all the queue needs is an "next activation head", which will be > the next job in the queue in the absence of blocking. When a job > blocks, syslets informs the workqueue and it moves on to the work on the > "next activation head". If a prior job unblocks, syslets informs the > queue and it moves the "next activation head" to the unblocked job. > What this is doing is implementing a really simple scheduler within a > single workqueue, which I'm unsure is actually a good idea since > schedulers are complex and tricky things, but it is probably worthy of > discussion.
The question is: is that significantly less overhead than just spawning a new full blown kernel thread ? enough to justify the complexity ? at the end of the day, it means allocating a stack (which on ppc64 is still 16K, I know it sucks)...
Ben.
| |