lkml.org 
[lkml]   [2008]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [4/7] dst: thread pool.
On Thu, Dec 18, 2008 at 07:03:12AM +1100, Benjamin Herrenschmidt (benh@kernel.crashing.org) wrote:
> > 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.
>
> The idea after KS was to use David Howells slow_work, maybe massaging
> the interfaces a bit.
>
> I haven't had time to dedicate to that yet myself. David, what are you
> up to with your initial implementation ?

I have no objections against any implementation which will be imported
into the tree and can change the code to use new API quickly, but since
there is no code right now, I created my own thread pool.

Particulary DST needs ability to sleep or queue the work to be processed
by the pool and API to flush/destroy the pool.

--
Evgeniy Polyakov


\
 
 \ /
  Last update: 2008-12-18 00:35    [W:0.083 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site