lkml.org 
[lkml]   [2009]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2009-12-23 09:41    [W:0.141 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site