Combined performance patches update for 2.4.19
From: [email protected]
Date: Sat, 24 Aug 2002 22:21:37 +1000
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
BTW, thank you for your great work!!
My pleasure, but really the hard work is done by the developers!
Sure, but your "performance" approach is really intersting! Do you use a benchmark?
I don't really have the time to benchmark these things any more than "it feels faster". Really I'm spending way too much time on this as it is and I'm not remotely any authority on what benchmarks to use.
Maybe I can find the time to run a few tests, can anyone suggest me an "intersting" test?
Quoted 13 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
I'm also testing the compressed cache (the patch you've discarded, and I got good performance!)
I'm thinking of eventually merging the latest version of this into 2.4.19
Quoted 8 lines
too
Quoted 1 line
since it can be enabled or disabled. Depends on the demand.
Just an hint ('cause I made some of the test you can see on the compressed cache web page on sourceforge),
if you use that patch boot your box with the
compressed=XXM in order to set the amount of the compressed cache. My box runs fast and happy with 32MiB or 64MiB of compressed cache. My box has 256MiB of Ram.
Quoted 5 lines
Ok thanks for the info. I believe the newer cc patch (not in my 2.4.18-ck4) is better anyway. I'm afraid the cc will be later in the piece assuming I can kill off the other bug I've created in the merge. I'd prefer to see a cc patch specifically for 2.4.19 as forward porting it to .19 and then to O(1) (and so on) are just too many steps.
Fair enough.
I think that soon we'll see the cc path for the 2.4.19, Rodrigo?
Ciao,
Paolo
Signature · 4 lines
Get your free email from www.linuxmail.org Powered by Outblaze
Quoted 11 lines · Paolo Ciarrocchi
From: [email protected]
Quoted 6 lines
Quoted 2 lines
Sure, but your "performance" approach is really intersting! Do you use a benchmark?
I don't really have the time to benchmark these things any more than "it feels faster". Really I'm spending way too much time on this as it is and I'm not remotely any authority on what benchmarks to use.
Maybe I can find the time to run a few tests, can anyone suggest me an "intersting" test?
Bob Matthews has a benchmark called irman, which tries to measure response time during a number of background loads.
I'm not sure it is too interesting in this case, though. People don't really care about the exact latency of sub-millisecond responses (should be the vast majority) but about the few times per minute where their mp3 skips.
Simple averages won't show the mp3 skips, because the number of fast responses are bound to be hundreds of thousands of times more common then the "mp3 skipping hickups".
Maybe the histogram mode of irman might show something useful ?
(then again, maybe it doesn't ... haven't tried yet)
http://people.redhat.com/bmatthews/irman/
kind regards,
Rik
Signature · 3 lines
Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/
Quoted 5 lines
From: [email protected]
Date: Sat, 24 Aug 2002 22:21:37 +1000Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
BTW, thank you for your great work!!
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
My pleasure, but really the hard work is done by the developers!
Sure, but your "performance" approach is really intersting! Do you use a benchmark?
I don't really have the time to benchmark these things any more than "it feels faster". Really I'm spending way too much time on this as it is and I'm not remotely any authority on what benchmarks to use.
Maybe I can find the time to run a few tests, can anyone suggest me an "intersting" test?
Not to toot our own horn too much, but..
We keep all the interestings tests we can find at: http://www.osdl.org/stp.
The big list is at: http://www.osdl.org/cgi-bin/eidetic.cgi?command=display&mod
ulename=tests
Plus you can become an associate, and get some time on hardware! cliffw
Quoted 36 lines
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
I'm also testing the compressed cache (the patch you've discarded, and I got good performance!)
I'm thinking of eventually merging the latest version of this into 2.4.19
Quoted 8 lines
too
Quoted 1 line
since it can be enabled or disabled. Depends on the demand.
Just an hint ('cause I made some of the test you can see on the compressed cache web page on sourceforge),
if you use that patch boot your box with the
compressed=XXM in order to set the amount of the compressed cache. My box runs fast and happy with 32MiB or 64MiB of compressed cache. My box has 256MiB of Ram.Quoted 5 lines
Ok thanks for the info. I believe the newer cc patch (not in my 2.4.18-ck4) is better anyway. I'm afraid the cc will be later in the piece assuming I can kill off the other bug I've created in the merge. I'd prefer to see a cc patch specifically for 2.4.19 as forward porting it to .19 and then to O(1) (and so on) are just too many steps.
Fair enough.
I think that soon we'll see the cc path for the 2.4.19, Rodrigo?Ciao,
PaoloSignature · 9 lines
Get your free email from www.linuxmail.org Powered by Outblaze - 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/