linux-kernel - Re: workqueue thing

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: <4B31C210.4010100@kernel.org>
Date:	Wed, 23 Dec 2009 16:09:04 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>, awalls@...ix.net,
	linux-kernel@...r.kernel.org, jeff@...zik.org,
	akpm@...ux-foundation.org, jens.axboe@...cle.com,
	rusty@...tcorp.com.au, cl@...ux-foundation.org,
	dhowells@...hat.com, arjan@...ux.intel.com, avi@...hat.com,
	johannes@...solutions.net, andi@...stfloor.org
Subject: Re: workqueue thing

Hello, Ingo.

On 12/23/2009 03:02 PM, Ingo Molnar wrote:
> Not from lack of trying though ;-)
> 
> One key thing i havent seen in this discussion are actual measurements. I 
> think a lot could be decided by simply testing this patch-set, by looking at 
> the hard numbers: how much faster (or slower) did a particular key workload 
> get before/after these patches.

As Jeff pointed out, I don't think this is gonna result in any major
performance increase or decrease.  The upside would be lowered cache
pressure coming from different types of works sharing the same context
(this will be very difficult to measure).  The downside would be the
more complex code workqueue has to run to manage the shared pool.  I
don't think it's gonna be anything noticeable either way.  Anyways, I
can try to set up a synthetic case which involves a lot of work
executions and at least make sure there's no noticeable slow down.

> Likewise, if there's a reduction in complexity, that is a tangible metric as 
> well: lets do a few conversions as part of the patch-set and see how much 
> simpler things have become as a result of it.

Doing several conversions shouldn't be difficult at all.  I'll try to
convert async and slow work.

> We really are not forced to the space of Gedankenexperiments here.

Sure but there's a reason why I posted the patchset without the actual
conversions.  I wanted to make sure that it's not rejected on the
ground of its basic design.  I thought it was acceptable after the
first RFC round but while trying to merge the scheduler part, Peter
seemed mightily unhappy with the whole thing, so this second RFC
round.  So, if anyone has major issues with the basic design, please
step forward *now* before I go spending more time working on it.

Another thing is that after spending a couple of months polishing the
patchset, it feels quite tiring to keep the patchset floating (you
know - Oh, this new thing should be merged into this patch.  Dang, now
I have to refresh 15 patches on top of it).  I would really appreciate
if I can set up a stable tree.  Would it be possible to set up a sched
devel branch?

Thanks.

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