This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Preheat CPU in benchtests
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Petr Baudis <pasky at ucw dot cz>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Fri, 26 Apr 2013 12:25:00 +0200
- Subject: Re: [PATCH] Preheat CPU in benchtests
- References: <20130423061028 dot GA6257 at domone dot kolej dot mff dot cuni dot cz> <m27gjtwcmf dot fsf at firstfloor dot org> <20130423151725 dot GA16219 at domone dot kolej dot mff dot cuni dot cz> <5176C0CD dot 4050705 at linux dot vnet dot ibm dot com> <20130423224912 dot GD31274 at machine dot or dot cz>
On Wed, Apr 24, 2013 at 12:49:12AM +0200, Petr Baudis wrote:
> On Tue, Apr 23, 2013 at 02:11:41PM -0300, Adhemerval Zanella wrote:
> > On 23-04-2013 12:17, OndÅej BÃlka wrote:
> > > On Tue, Apr 23, 2013 at 07:22:16AM -0700, Andi Kleen wrote:
> > >> OndÅej BÃlka <neleai@seznam.cz> writes:
> > >>
> > >>> Benchmarks now are affected by cpu scaling when initialy run at low
> > >>> frequency.
> > >>>
> > >>> Following benchmark runs nonsensial loop first to ensure that benchmark
> > >>> are measured at maximal frequency. This greatly cuts time needed to
> > >>> get accurate results.
>
> It seems to me pre-heating for a fixed time period (e.g. 500ms) would be
> safer than pre-heating for a fixed number of cycles. However, I'm not
> sure about the exact CPU frequency governor rules usually employed.
>
> > >> FWIW it's generally safer to disable frequency scaling explicitely
> > >> through sysfs (but that needs root), as the reaction time of the
> > >> p-state governour can be unpredictable.
> > > Which needs root, so it would request typing password each time you run
> > > automated benchmarks.
> > >
> > I see it should be up to developer to setup the environment and to report
> > its findings and configuration used. Maybe we might add hooks though
> > env. vars or additional logic on the Makefile/script that runs the benchmark
> > (to bind cpu/memory, setup machine scaling, etc.), but I don't think it
> > should in benchmark logic to setup such things.
>
> Maybe we should just test whether the conditions are right, i.e. if
> frequency scaling is disabled; if we detect a problem, print a fat
> warning so that the user knows their results aren't reliable, plus
> print an one-liner suggestion for the user to run to fix the situation?
>
If you wrote generic a utility that setups enviroment without user
intervention other than installing I would accept that.
It could be suid binary that sets frequency,
invokes benchmark as nobody with env variable for cpu affinity,
restores frequency/governor.