This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Preheat CPU in benchtests
- From: Torvald Riegel <triegel at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Petr Baudis <pasky at ucw dot cz>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Fri, 17 May 2013 12:40:52 +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> <20130424071658 dot GA6406 at domone dot kolej dot mff dot cuni dot cz>
On Wed, 2013-04-24 at 09:16 +0200, OndÅej BÃlka wrote:
> 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:
> > > >> 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?
>
> Warning has problem that it will get lost in wall of text.
I suppose that eventually, we'll want to process the benchmark results
automatically anyway. To do this, we need the information that we'd be
warning about anyway. Thus, even if a user might not observe the
warning always, this is no reason to not warn about it, nor to have this
information available once we have more advanced reporting in place.