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]
Date:	Wed, 28 Jan 2009 12:33:28 +0100
From:	Frédéric Weisbecker <fweisbec@...il.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Oleg Nesterov <oleg@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Alasdair G Kergon <agk@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [RFC v2][PATCH] create workqueue threads only when needed

2009/1/28 Peter Zijlstra <a.p.zijlstra@...llo.nl>:
> On Wed, 2009-01-28 at 04:02 +0100, Oleg Nesterov wrote:
>>
>> I must admit, I don't like this patch. Perhaps I am wrong, mostly I
>> dislike the complications it adds.
>>
>> Anybody else please vote for this change?
>
> Because you asked ;-)
>
> I too am not particularly fond of it, for much the same reasons you
> mentioned.
>
> While I think its good to reduce the number of random kernel threads,
> I'm afraid this isn't a good way to do so.
>
> Why does everybody and his pony create their own workqueue, is that
> really because it deadlocks with keventd, or are there other reasons, if
> so, which, and can we solve those?


Even with the approach of shadow workqueues, these call sites that
create pointless workqueues
are still a problem that should be fixed, since they consume memory
for their workqueue.

The reasons for these callsites are not easy to guess, they are not so
much commented and it's
hard to imagine if this is because of deadlocks with kevents, too long
work which can starve other
kevent work, or just funny workqueues....

Depending on the reason, I guess most of them can become threads
created and destroyed on the fly,
or async functions as Arjan suggested, or simple kevent works.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ