Messages in this thread | | | Subject | Re: [Ksummit-2008-discuss] Delayed interrupt work, thread pools | From | Benjamin Herrenschmidt <> | Date | Tue, 01 Jul 2008 23:38:31 +1000 |
| |
On Tue, 2008-07-01 at 06:53 -0600, Matthew Wilcox wrote: > On Tue, Jul 01, 2008 at 10:45:35PM +1000, Benjamin Herrenschmidt wrote: > > In various areas (I'll come up with some examples later), kernel code > > such as drivers want to defer some processing to "task level", for > > various reasons such as locking (taking mutexes), memory allocation, > > interrupt latency, or simply doing things that may take more time than > > is reasonable to do at interrupt time or do things that may block. > > > > Currently, the main mechanism we provide to do that is workqueues. They > > somewhat solve the problem, but at the same time, somewhat can make it > > worse. > > Why not just use a dedicated thread? The API to start / stop threads is > now pretty easy to use.
A dedicated thread isn't far from a dedicated workqueue. The thread can be blocked servicing a page fault and that will delay any further work.
In the case of spufs, we could solve that by having a dedicated thread per context. That's probably what we'll do for our proof-of-concept implementation of our new ideas. But that sounds overkill, there shouldn't be -that- much page faults. Similar comes with gfx cards with MMUs, etc.. we'd end up with shitload of dedicated threads mostly staying there sleeping and wasting kernel resources.
Another option I though about would be something akin to some of the threadlet discussions (or whatever we call those nowadays). ie, have the workqueue fork when it blocks basically. That would require some API changes as current drivers may rely on the fact that all workqueues tasks are serialized though.
Cheers, Ben.
| |