> -----Original Message-----
> From: Linus Torvalds [mailto:[email protected]]
> Sent: Monday, March 24, 2003 12:40 AM
> To: [email protected]
> Subject: Re: lmbench results for 2.4 and 2.5 -- updated results
>
>
> >--page fault (is this significant?)
>
> I don't think so, there's something strange with the lmbench pagefault
> tests, it only has one significant digit of accuracy, and I don't even
> know what it is testing. Because of the single lack of precision, it's
> hard to tell what the real change is.
>
This single digit accuracy is coming from a minor integer division bug
in lmbench.
Appended LMbench patch should resolve it.
Thanks,
-Venkatesh
--- LMbench/src/lat_pagefault.c.org Mon Mar 24 10:40:46 2003
+++ LMbench/src/lat_pagefault.c Mon Mar 24 10:54:34 2003
@@ -67,5 +67,5 @@
n++;
}
use_int(sum);
- fprintf(stderr, "Pagefaults on %s: %d usecs\n", file, usecs/n);
+ fprintf(stderr, "Pagefaults on %s: %f usecs\n", file, (1.0 *
usecs) / n);
}
On Mon, Mar 24, 2003 at 11:53:44AM -0800, Pallipadi, Venkatesh wrote:
> --- LMbench/src/lat_pagefault.c.org Mon Mar 24 10:40:46 2003
> +++ LMbench/src/lat_pagefault.c Mon Mar 24 10:54:34 2003
> @@ -67,5 +67,5 @@
> n++;
> }
> use_int(sum);
> - fprintf(stderr, "Pagefaults on %s: %d usecs\n", file, usecs/n);
> + fprintf(stderr, "Pagefaults on %s: %f usecs\n", file, (1.0 *
> usecs) / n);
> }
It's been a long time since I've looked at this benchmark, has anyone
stared at it and do you believe it measures anything useful? If not,
I'll drop it from a future release. If I remember correctly what I
was trying to do was to measure the cost of setting up the mapping
but I might be crackin smoke.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
>> --- LMbench/src/lat_pagefault.c.org Mon Mar 24 10:40:46 2003
>> +++ LMbench/src/lat_pagefault.c Mon Mar 24 10:54:34 2003
>> @@ -67,5 +67,5 @@
>> n++;
>> }
>> use_int(sum);
>> - fprintf(stderr, "Pagefaults on %s: %d usecs\n", file, usecs/n);
>> + fprintf(stderr, "Pagefaults on %s: %f usecs\n", file, (1.0 *
>> usecs) / n);
>> }
>
> It's been a long time since I've looked at this benchmark, has anyone
> stared at it and do you believe it measures anything useful? If not,
> I'll drop it from a future release. If I remember correctly what I
> was trying to do was to measure the cost of setting up the mapping
> but I might be crackin smoke.
On a slightly related note, I played with lmbench a bit over the weekend,
but the results were too unstable to be useful ... they're also too short
to profile ;-(
I presume it does 100 iterations of a test (like fork latency?). Or does
it just do one? Can I make it do 1,000,000 iterations or something
fairly easily ? ;-) I didn't really look closely, just apt-get install
lmbench ...
Thanks,
M.
"Martin J. Bligh" <[email protected]> wrote:
>
> On a slightly related note, I played with lmbench a bit over the weekend,
> but the results were too unstable to be useful ... they're also too short
> to profile ;-(
>
> I presume it does 100 iterations of a test (like fork latency?). Or does
> it just do one? Can I make it do 1,000,000 iterations or something
> fairly easily ? ;-) I didn't really look closely, just apt-get install
> lmbench ...
Yes, that is something I've wanted several times. Just a way to say "run
this test for ever so I can profile the thing".
Even a sleazy environment string would suffice.
On Mon, Mar 24, 2003 at 03:36:02PM -0800, Andrew Morton wrote:
> "Martin J. Bligh" <[email protected]> wrote:
> >
> > On a slightly related note, I played with lmbench a bit over the weekend,
> > but the results were too unstable to be useful ... they're also too short
> > to profile ;-(
> >
> > I presume it does 100 iterations of a test (like fork latency?). Or does
> > it just do one? Can I make it do 1,000,000 iterations or something
> > fairly easily ? ;-) I didn't really look closely, just apt-get install
> > lmbench ...
>
> Yes, that is something I've wanted several times. Just a way to say "run
> this test for ever so I can profile the thing".
>
> Even a sleazy environment string would suffice.
It's been there, I suppose you need to read the source to figure it out
though the lmbench script also plays with this I believe.
work ~/LMbench2/bin/i686-pc-linux-gnu ENOUGH=1000000 time bw_pipe
Pipe bandwidth: 655.37 MB/sec
real 0m23.411s
user 0m0.480s
sys 0m1.180s
work ~/LMbench2/bin/i686-pc-linux-gnu time bw_pipe
Pipe bandwidth: 809.81 MB/sec
real 0m2.821s
user 0m0.480s
sys 0m1.180s
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
>> > I presume it does 100 iterations of a test (like fork latency?). Or does
>> > it just do one? Can I make it do 1,000,000 iterations or something
>> > fairly easily ? ;-) I didn't really look closely, just apt-get install
>> > lmbench ...
>>
>> Yes, that is something I've wanted several times. Just a way to say "run
>> this test for ever so I can profile the thing".
>>
>> Even a sleazy environment string would suffice.
>
> It's been there, I suppose you need to read the source to figure it out
> though the lmbench script also plays with this I believe.
Yay! Thank you.
> work ~/LMbench2/bin/i686-pc-linux-gnu ENOUGH=1000000 time bw_pipe
> Pipe bandwidth: 655.37 MB/sec
> real 0m23.411s
> user 0m0.480s
> sys 0m1.180s
>
> work ~/LMbench2/bin/i686-pc-linux-gnu time bw_pipe
> Pipe bandwidth: 809.81 MB/sec
>
> real 0m2.821s
> user 0m0.480s
> sys 0m1.180s
Mmmm. Any idea why the results are so dramtically different? 655 vs 809?
Looks odd ;-)
m.
> Mmmm. Any idea why the results are so dramtically different? 655 vs 809?
Yeah, two run-away mutt processes (*) eating up all the CPU. When ENOUGH
is small, i.e., less than a second or so, LMbench does a series of tests
and takes the mean (I believe, look at the source, lib_timing.c and *.h).
When ENOUGH is big it just does one run and reports that. So the big run
was long enough it was competing for time slices and the default ones are
short enough they get the whole slice. It's actually possible to run
LMbench on a loaded system and get fairly accurate results if you have
a decent enough clock.
(*) I use rsh to get into the main machine here and ever since Red Hat 7.?
if I'm rsh-ed in from a laptop, put the laptop to sleep and the connection
gets dropped, my mutt sessions don't get SIGHUP or whatever they should
get and they start sucking up CPU like there is no tomorrow. Does anyone
know of a fix for this?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> work ~/LMbench2/bin/i686-pc-linux-gnu ENOUGH=1000000 time bw_pipe
> Pipe bandwidth: 655.37 MB/sec
> real 0m23.411s
> user 0m0.480s
> sys 0m1.180s
>
> work ~/LMbench2/bin/i686-pc-linux-gnu time bw_pipe
> Pipe bandwidth: 809.81 MB/sec
>
> real 0m2.821s
> user 0m0.480s
> sys 0m1.180s
OK, is a bit more stable now ... before:
Process fork+exit: 294.4118 microseconds
Process fork+exit: 279.1500 microseconds
Process fork+exit: 280.0000 microseconds
Process fork+exit: 280.0000 microseconds
Process fork+exit: 277.2222 microseconds
Process fork+exit: 286.0000 microseconds
Process fork+exit: 277.6231 microseconds
Process fork+exit: 307.1176 microseconds
Process fork+exit: 295.4706 microseconds
Process fork+exit: 294.3529 microseconds
after:
Process fork+exit: 298.4124 microseconds
Process fork+exit: 298.6746 microseconds
Process fork+exit: 297.7784 microseconds
Process fork+exit: 294.8297 microseconds
Process fork+exit: 299.6249 microseconds
Process fork+exit: 297.6771 microseconds
Process fork+exit: 297.9801 microseconds
Process fork+exit: 293.1421 microseconds
Process fork+exit: 281.9868 microseconds
I can probably butcher that around by taking a few derived medians and
averages to get pretty consistent numbers out of it (std dev < 1% for 99%
of the time). Though 10 runs with ENOUGH=1000000 is kinda slow for all
tests, so I probably won't be able to do this by default for every version.
If there are any more suggestions on added stability, I'd love to hear them.
Is cool to have something big enough to profile too ;-)
Thanks very much,
M.
In general, LMbench optimizes for fast results over exactness. You can
definitely get more accurate results by doing longer runs. My view
at the time of writing it was that I was looking for the broad stroke
results because I was trying to measure differences between various
operating systems. There was more than enough to show so the results
didn't need to be precise, getting people to run the benchmark and
report results was more important.
If people are doing release runs to see if there are regressions, I
think that setting ENOUGH up to something longer is a good idea.
If there is enough interest, I could spend some time on this and
try and make a more accurate way to get results. Let me know.
On Tue, Mar 25, 2003 at 10:23:50AM -0800, Martin J. Bligh wrote:
> > work ~/LMbench2/bin/i686-pc-linux-gnu ENOUGH=1000000 time bw_pipe
> > Pipe bandwidth: 655.37 MB/sec
> > real 0m23.411s
> > user 0m0.480s
> > sys 0m1.180s
> >
> > work ~/LMbench2/bin/i686-pc-linux-gnu time bw_pipe
> > Pipe bandwidth: 809.81 MB/sec
> >
> > real 0m2.821s
> > user 0m0.480s
> > sys 0m1.180s
>
> OK, is a bit more stable now ... before:
>
> Process fork+exit: 294.4118 microseconds
> Process fork+exit: 279.1500 microseconds
> Process fork+exit: 280.0000 microseconds
> Process fork+exit: 280.0000 microseconds
> Process fork+exit: 277.2222 microseconds
> Process fork+exit: 286.0000 microseconds
> Process fork+exit: 277.6231 microseconds
> Process fork+exit: 307.1176 microseconds
> Process fork+exit: 295.4706 microseconds
> Process fork+exit: 294.3529 microseconds
>
> after:
>
> Process fork+exit: 298.4124 microseconds
> Process fork+exit: 298.6746 microseconds
> Process fork+exit: 297.7784 microseconds
> Process fork+exit: 294.8297 microseconds
> Process fork+exit: 299.6249 microseconds
> Process fork+exit: 297.6771 microseconds
> Process fork+exit: 297.9801 microseconds
> Process fork+exit: 293.1421 microseconds
> Process fork+exit: 281.9868 microseconds
>
> I can probably butcher that around by taking a few derived medians and
> averages to get pretty consistent numbers out of it (std dev < 1% for 99%
> of the time). Though 10 runs with ENOUGH=1000000 is kinda slow for all
> tests, so I probably won't be able to do this by default for every version.
> If there are any more suggestions on added stability, I'd love to hear them.
>
> Is cool to have something big enough to profile too ;-)
>
> Thanks very much,
>
> M.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> In general, LMbench optimizes for fast results over exactness. You can
> definitely get more accurate results by doing longer runs. My view
> at the time of writing it was that I was looking for the broad stroke
> results because I was trying to measure differences between various
> operating systems. There was more than enough to show so the results
> didn't need to be precise, getting people to run the benchmark and
> report results was more important.
>
> If people are doing release runs to see if there are regressions, I
> think that setting ENOUGH up to something longer is a good idea.
> If there is enough interest, I could spend some time on this and
> try and make a more accurate way to get results. Let me know.
Well, I'd certainly be interested ... I think it's almost inevitable
that there's a bit of variations in timing ... the way I normally deal
with that is to do, say 30 runs, sort the results, throw away the top
and bottom 10, and take the average of the middle 10.
Now at the moment, I presume you're presenting back an average of all
the runs you did ... if so, that looses some of the data to calculate
that, so we have to do multiple runs, etc and it all gets a bit slower.
If you can do that kind of stats op inside the lmbench tools, it
might help. Of course, I can do that outside as a wrapper, but then
there's the fork/exec setup time of the program to consider, etc etc.
The other interesting question is *why* there's so much variability
in results in the first place. Indicative of some inner kernel problem?
People have talked about page colouring, etc before, but I've tried
before, and never mananged to generate any data showing a benefit for
std dev of runs or whatever. Incidentally, this means that giving std
dev (of the used subset, and all results) from lmbench would be fun ;-)
The other problem was the "make it long enough to profile" thing ...
I think the ENOUGH trick you showed us is perfectly sufficent to solve
that one ;-)
Thanks,
M.