Combined performance patches update for 2.4.19

Combined performance patches update for 2.4.19

[conman]

I've completed merging the following patches:

O(1) scheduler
Preemptible
Low latency

against 2.4.19

I've put the patch up here:
http://kernel.kolivas.net

This one definitely feels faster.
Feel free to give it a try and tell me what you think.

Con Kolivas

Re: Combined performance patches update for 2.4.19

[conman]

Quoting Rik van Riel <riel@conectiva.com.br>:

> On Fri, 23 Aug 2002 conman@kolivas.net wrote:
> 
> > I've completed merging the following patches:
> >
> > O(1) scheduler
> > Preemptible
> > Low latency
> 
> Could I interest you in the -rmap VM ? ;)
> 
> http://surriel.com/patches/
> 
> (needs one extra preempt patchlet, which I'll give to you if you want)
> 

Sure I'll give it a go, but it might kill me trying :P

Con.

Re: Combined performance patches update for 2.4.19

[Rik van Riel]

On Sat, 24 Aug 2002 conman@kolivas.net wrote:
> Quoting Rik van Riel <riel@conectiva.com.br>:
> > On Fri, 23 Aug 2002 conman@kolivas.net wrote:
> >
> > > I've completed merging the following patches:
> > >
> > > O(1) scheduler
> > > Preemptible
> > > Low latency
> >
> > Could I interest you in the -rmap VM ? ;)
> >
> > http://surriel.com/patches/
>
> Sure I'll give it a go, but it might kill me trying :P

OK, here's a little patch to be able to combine rmap and preempt.

have fun,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/


===== include/linux/mm.h 1.47 vs edited =====
--- 1.47/include/linux/mm.h	Tue Aug  6 15:59:20 2002
+++ edited/include/linux/mm.h	Fri Aug 23 12:48:44 2002
@@ -337,6 +337,7 @@
 	 * busywait with less bus contention for a good time to
 	 * attempt to acquire the lock bit.
 	 */
+	preempt_disable();
 #ifdef CONFIG_SMP
 	while (test_and_set_bit(PG_chainlock, &page->flags)) {
 		while (test_bit(PG_chainlock, &page->flags))
@@ -350,6 +351,7 @@
 #ifdef CONFIG_SMP
 	clear_bit(PG_chainlock, &page->flags);
 #endif
+	preempt_enable();
 }

 /*

Re: Combined performance patches update for 2.4.19

[conman]

Quoting Paolo Ciarrocchi <ciarrocchi@linuxmail.org>:

> Hi Kon, 
> I've just tried your patch with a fresh 2.4.19.
> here it goes the dmesg output,
> there is something wrong with preempt:
> 
> note: consoletype[499] exited with preempt_count 1

Yes if you read my FAQ you'd see this is a known issue. I need some higher help
to sort this out

> BTW, thank you for your great work!!

My pleasure, but really the hard work is done by the developers!

> 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 too
since it can be enabled or disabled. Depends on the demand.

Con.

Re: Combined performance patches update for 2.4.19

[conman]

Quoting Paolo Ciarrocchi <ciarrocchi@linuxmail.org>:

> > > note: consoletype[499] exited with preempt_count 1
> > 
> > Yes if you read my FAQ you'd see this is a known issue. I need some higher
> help
> > to sort this out
> OK, did you contact Robert Love?

No I don't really want to bother the real developers because they are doing real
work. What I'm doing could almost be called butchering, but it definitely gave
me a performance advantage and seemed a shame to not share the work given the
effort I put in.

> > > 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.

> > > 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
> too
> > 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.

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. 

Cheers,
Con Kolivas

Re: Combined performance patches update for 2.4.19

[Paolo Ciarrocchi]

From: conman@kolivas.net
Date: Sat, 24 Aug 2002 22:21:37 +1000

> > > > 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?

 
> > > > 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
> > too
> > > 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.
> 
> 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
-- 
Get your free email from www.linuxmail.org 


Powered by Outblaze

Re: Combined performance patches update for 2.4.19

[Rik van Riel]

On Sun, 25 Aug 2002, Paolo Ciarrocchi wrote:
> From: conman@kolivas.net
>
> > > 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
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Re: Combined performance patches update for 2.4.19

[Paolo Ciarrocchi]

From: Rik van Riel <riel@conectiva.com.br>

[...]
> > 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/
Well... I tried irman, and here it goes the results:

Test: NULL
Kernel                         max       min       avg    stddev
2.4.18                      45.955     0.004     0.005     0.061
2.4.18-0.24pre3              0.121     0.005     0.005     0.001
2.4.19                       1.683     0.005     0.005     0.002
2.4.19-ck3                   1.694     0.005     0.005     0.002
2.4.19-ck3-aa                0.200     0.005     0.005     0.001
2.4.19-ck3-rmap              1.628     0.005     0.005     0.002
2.5.31                       1.636     0.006     0.007     0.002

Test: MEMORY
Kernel                         max       min       avg    stddev
2.4.18                      69.471     0.005     0.010     0.554
2.4.18-0.24pre3             70.031     0.005     0.010     0.546
2.4.19                      60.058     0.005     0.011     0.558
2.4.19-ck3                 150.216     0.005     0.009     0.720
2.4.19-ck3-aa              150.075     0.005     0.008     0.621
2.4.19-ck3-rmap            150.059     0.005     0.009     0.674
2.5.31                       1.823     0.005     0.007     0.002

Test: FILE_IO
Kernel                         max       min       avg    stddev
2.4.18                     190.042     0.005     0.019     1.452
2.4.18-0.24pre3            325.509     0.005     0.017     1.379
2.4.19                     190.033     0.005     0.022     1.525
2.4.19-ck3                1050.048     0.005     0.015     2.196
2.4.19-ck3-aa             1363.153     0.005     0.014     2.177
2.4.19-ck3-rmap            450.073     0.005     0.016     2.097
2.5.31                     610.021     0.006     0.019     2.314

Test: PROCESS
Kernel                         max       min       avg    stddev
2.4.18                     350.056     0.005     0.068     2.548
2.4.18-0.24pre3            270.138     0.005     0.068     2.439
2.4.19                     270.238     0.005     0.075     2.594
2.4.19-ck3                1710.017     0.005     0.022     4.293
2.4.19-ck3-aa             1620.023     0.005     0.023     4.298
2.4.19-ck3-rmap           1630.020     0.005     0.025     4.724
2.5.31                    1171.021     0.006     0.026     4.354

Ciao,
              Paolo
-- 
Get your free email from www.linuxmail.org 


Powered by Outblaze

Re: Combined performance patches update for 2.4.19

[Cliff White]

> From: conman@kolivas.net
> Date: Sat, 24 Aug 2002 22:21:37 +1000
> 
> > > > > 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?

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
> 
>  
> > > > > 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
> > > too
> > > > 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.
> > 
> > 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
> -- 
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>