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]
Date:	Tue, 27 Sep 2011 15:39:09 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Turner <pjt@...gle.com>,
	Venki Pallipadi <venki@...gle.com>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] sched: fix nohz idle load balancer issues


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

> * Ingo Molnar <mingo@...e.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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ