From: Ingo Molnar <mingo@elte.hu>
To: Michael Gerdau <mgd@technosis.de>
Cc: linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Nick Piggin <npiggin@suse.de>,
Gene Heskett <gene.heskett@gmail.com>,
Juliusz Chroboczek <jch@pps.jussieu.fr>,
Mike Galbraith <efault@gmx.de>,
Peter Williams <pwil3058@bigpond.net.au>,
ck list <ck@vds.kolivas.org>,
Thomas Gleixner <tglx@linutronix.de>,
William Lee Irwin III <wli@holomorphy.com>,
Andrew Morton <akpm@linux-foundation.org>,
Bill Davidsen <davidsen@tmr.com>, Willy Tarreau <w@1wt.eu>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [REPORT] cfs-v5 vs sd-0.46
Date: Tue, 24 Apr 2007 10:51:05 +0200 [thread overview]
Message-ID: <20070424085105.GA12329@elte.hu> (raw)
In-Reply-To: <200704241041.53762.mgd@technosis.de>
* Michael Gerdau <mgd@technosis.de> wrote:
> > Here i'm assuming that the vmstats are directly comparable: that
> > your number-crunchers behave the same during the full runtime - is
> > that correct?
>
> Yes, basically it does (disregarding small fluctuations)
ok, good.
> I'll see whether I can produce some type of absolute performance
> measure as well. Thinking about it I guess this should be fairly
> simple to implement.
oh, you are writing the number-cruncher? 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. If you
measure time then the best is to use long long and nanoseconds and the
monotonic clocksource:
unsigned long long rdclock(void)
{
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
return ts.tv_sec * 1000000000ULL + ts.tv_nsec;
}
(link to librt via -lrt to pick up clock_gettime())
The cost of a clock_gettime() (or of a gettimeofday()) can be a couple
of microseconds on some systems, so it shouldnt be done too frequently.
Plus an absolute metric of "the whole workload took X.Y seconds" is
useful too.
Ingo
next prev parent reply other threads:[~2007-04-24 8:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-24 7:37 [REPORT] cfs-v5 vs sd-0.46 Michael Gerdau
2007-04-24 7:53 ` Ingo Molnar
2007-04-24 8:16 ` Michael Gerdau
2007-04-24 8:23 ` Ingo Molnar
2007-04-24 8:41 ` Michael Gerdau
2007-04-24 8:51 ` Ingo Molnar [this message]
2007-04-24 9:06 ` Michael Gerdau
2007-04-26 1:06 ` [ck] " Con Kolivas
2007-04-26 6:10 ` Michael Gerdau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070424085105.GA12329@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=ck@vds.kolivas.org \
--cc=davidsen@tmr.com \
--cc=efault@gmx.de \
--cc=gene.heskett@gmail.com \
--cc=jch@pps.jussieu.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=mgd@technosis.de \
--cc=npiggin@suse.de \
--cc=pwil3058@bigpond.net.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox