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: <20091223084935.GC25240@elte.hu>
Date:	Wed, 23 Dec 2009 09:49:35 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Tejun Heo <tj@...nel.org>
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


* Tejun Heo <tj@...nel.org> wrote:

> Hello,
> 
> On 12/23/2009 05:37 PM, Ingo Molnar wrote:
> >> Sure, fair enough but there's also a different side.  It'll allow much 
> >> easier implementation of things like in-kernel media presence polling (I 
> >> have some code for this but it's still just forming) and per-device.  It 
> >> gives a much easier tool to extract concurrency and thus opens up new 
> >> possibilities.
> >>
> >> So, anyways, alright, I'll go try some conversions.
> > 
> > Well, but note that you are again talking performance. Concurrency
> > _IS_ performance: either in terms of reduced IO/app/request latency
> > or in terms of CPU utilization.
> 
> I wasn't talking about performance above.  Easiness or flexibility to 
> extract concurrency opens up possibilities for new things or easier ways of 
> doing things.  It affects the design process.  You don't have to jump 
> through hoops for concurrency management and removing that restriction 
> results in lower amount of convolution and simplifies design.

Which is why i said this in the next paragraph:

> > ( Plus reduction in driver complexity can be measured as well, in the 
> >   diffstat space.)

A new facility that is so mysterious that it cannot be shown to have any 
performance/scalability/latency benefit _nor_ can it be shown to reduce driver 
complexity simply does not exist IMO.

A tangle benefit has to show up _somewhere_ - if not in the performance space 
then in the diffstat space (and vice versa) - that's all what i'm arguing.

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