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
Quoting Rik van Riel <[email protected]>:
> On Fri, 23 Aug 2002 [email protected] 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.
On Sat, 24 Aug 2002 [email protected] wrote:
> Quoting Rik van Riel <[email protected]>:
> > On Fri, 23 Aug 2002 [email protected] 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();
}
/*
Quoting Paolo Ciarrocchi <[email protected]>:
> 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.
Quoting Paolo Ciarrocchi <[email protected]>:
> > > 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
From: [email protected]
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 http://www.linuxmail.org
Powered by Outblaze
On Sun, 25 Aug 2002, Paolo Ciarrocchi wrote:
> From: [email protected]
>
> > > 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/
From: Rik van Riel <[email protected]>
[...]
> > 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 http://www.linuxmail.org
Powered by Outblaze
> From: [email protected]
> 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 http://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/
>