[lkml]   [2008]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [4/7] dst: thread pool.
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 <>

Have you looked at the last discussion involving thread pools in Linux?
BenH brought up the topic earlier this year, it is archived on

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 <><

 \ /
  Last update: 2008-12-17 16:57    [W:0.045 / U:3.000 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site