Messages in this thread | | | Date | Wed, 23 Dec 2009 09:37:05 +0100 | From | Ingo Molnar <> | Subject | Re: workqueue thing |
| |
* Tejun Heo <tj@kernel.org> wrote:
> Hello, > > On 12/23/2009 05:01 PM, Ingo Molnar wrote: > > At least as far as i'm concerned, i'd like to see actual uses. It's a big > > linecount increase all things considered: > > > > 20 files changed, 2783 insertions(+), 660 deletions(-) > > > > and you say it _wont_ help performance/scalability (this aspect > > wasnt clear to me from previous discussions), > > I'm just not sure how it would turn out. I guess it would be an overall win > under loaded situations due to lowered cache footprint but I don't think it > will be anything which would stand out. > > > so the (yet to be seen) complexity reduction in other code ought to be > > worth it. > > 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.
Both metrics can be measured (and there's a massive effort underway to help measure such things - see current results under tools/perf/ in your favorite kernel repo ;-)
(Plus reduction in driver complexity can be measured as well, in the diffstat space.)
So there's no leap of faith needed really, IMHO.
Ingo
| |