Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [4/7] dst: thread pool. | Date | Wed, 17 Dec 2008 16:55:04 +0100 |
| |
On Wednesday 17 December 2008, Evgeniy Polyakov wrote: > > Thread pool abstraction allows to schedule a work to be performed > on behalf of kernel thread. One does not operate with threads itself, > instead user provides setup and cleanup callbacks for thread pool itself, > and action and cleanup callbacks for each submitted work. > > Each worker has private data initialized at creation time and data, > provided by user at scheduling time. > > When action is being performed, thread can not be used by other users, > instead they will sleep until there is free thread to pick their work. > > Thread pool is used for crypto processing of incoming and outgoing IO > requests to reduce the overall overhead. > > Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net>
Have you looked at the last discussion involving thread pools in Linux? BenH brought up the topic earlier this year, it is archived on https://lists.linux-foundation.org/pipermail/ksummit-2008-discuss/2008-July/000213.html
So while it seems that there is clearly a use for such infrastructure, my feeling is that it should not be part of dst, but rather live in a location where it can be used by every subsystem.
Of course getting it there means another flame war^W^W discussion about what the right interface should look like.
My personal feeling is that the interface should look a lot like the existing work queues, to the point where you can easily convert drivers between them, or even move all work queues over to thread pools.
Arnd <><
| |