lkml.org 
[lkml]   [2011]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1] sched: fix nohz idle load balancer issues

* Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com> wrote:

> * Ingo Molnar <mingo@elte.hu> [2011-09-27 08:32:24]:
>
> > What are the tasks doing which are running - are they plain burning
> > CPU time? If the tasks do something more complex, do you also have a
> > measure of how much work gets done by the workload, per second?
>
> They are simple cpu hogs at this time.
>
> > Percentual changes in that metric would be nice to include in an
> > additional column - that way we can see that it's not only idle
> > that has gone down, but workload performance has gone up too.
>
> Ok, good point.
>
> > In fact even if there was only a CPU burning loop in the workload it
> > would be nice to make that somewhat more sophisticated by letting it
> > process some larger array that has a cache footprint. This mimics
> > real workloads that don't just spin burning CPU time but do real data
> > processing.
> >
> > For any non-trivial workload it's possible to reduce idle time
> > without much increase in work done and in fact it's possible to
> > decrease idle time *and* work done - so we need to see more clearly
> > here and make sure it's all an improvement.
>
> Ok - I will run a cpu intensive benchmark and get some numbers on
> how benchmark score varies with the patch applied. I can pick a
> simple matrix multiplication type benchmark, unless you have other
> suggestions!

Yeah, matrix multiplication would be fine i think.

You could create it yourself and add it into
tools/perf/bench/cpu-matrix.c as a new 'perf bench cpu matrix'
testcase - perhaps with a '-s 10m' parameter that defines the size of
the matrices, and a '-i 1000' parameter to specify the number of
iterations - or so.

We could use that for scheduler HPC benchmarking in the future as
well.

Thanks,

Ingo


\
 
 \ /
  Last update: 2011-09-27 15:43    [W:0.054 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site