[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200704241106.41912.mgd@technosis.de>
Date: Tue, 24 Apr 2007 11:06:29 +0200
From: Michael Gerdau <mgd@...hnosis.de>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Nick Piggin <npiggin@...e.de>,
Gene Heskett <gene.heskett@...il.com>,
Juliusz Chroboczek <jch@....jussieu.fr>,
Mike Galbraith <efault@....de>,
Peter Williams <pwil3058@...pond.net.au>,
ck list <ck@....kolivas.org>,
Thomas Gleixner <tglx@...utronix.de>,
William Lee Irwin III <wli@...omorphy.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Bill Davidsen <davidsen@....com>, Willy Tarreau <w@....eu>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [REPORT] cfs-v5 vs sd-0.46
> oh, you are writing the number-cruncher?
Yep.
> In general the 'best'
> performance metrics for scheduler validation are the ones where you have
> immediate feedback: i.e. some ops/sec (or ops per minute) value in some
> readily accessible place, or some "milliseconds-per-100,000 ops" type of
> metric - whichever lends itself better to the workload at hand.
I'll have to see whether that works out. I don't have an easily
available ops/sec but I guess I could create something similar.
> If you
> measure time then the best is to use long long and nanoseconds and the
> monotonic clocksource:
[snip]
Thanks, I will implement that, for Linux anyway.
> Plus an absolute metric of "the whole workload took X.Y seconds" is
> useful too.
That's the easiest to come by and is already available.
Best,
Michael
--
Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar
Sitz Hamburg; HRB 89145 Amtsgericht Hamburg
Vote against SPAM - see http://www.politik-digital.de/spam/
Michael Gerdau email: mgd@...hnosis.de
GPG-keys available on request or at public keyserver
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists