linux-kernel - Re: [4/7] dst: thread pool.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081217233203.GA30039@ioremap.net>
Date:	Thu, 18 Dec 2008 02:32:03 +0300
From:	Evgeniy Polyakov <zbr@...emap.net>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>
Subject: Re: [4/7] dst: thread pool.

On Thu, Dec 18, 2008 at 07:03:12AM +1100, Benjamin Herrenschmidt (benh@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/