Re: workqueue thing

[Ingo Molnar]

* Tejun Heo <tj@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/