With the patch against 2.4.19:
Scheduler O(1), Preemptible, Low Latency
I have now added two extra alternative patches that include
either Rik's rmap (thanks Rik) or AA's vm changes (thanks to Nuno Monteiro for
merging this)
For the record, with the (very) brief usage of these two patches I found the
rmap patch a little faster. This is very subjective and completely untested.
Check them out here and tell me what you think(please read the FAQ):
http://kernel.kolivas.net
Con Kolivas
>
> With the patch against 2.4.19:
>
> Scheduler O(1), Preemptible, Low Latency
>
> I have now added two extra alternative patches that include
> either Rik's rmap (thanks Rik) or AA's vm changes (thanks to Nuno Monteiro for
> merging this)
>
> For the record, with the (very) brief usage of these two patches I found the
> rmap patch a little faster. This is very subjective and completely untested.
>
> Check them out here and tell me what you think(please read the FAQ):
> http://kernel.kolivas.net
Tried this patch and it applied fine.
The target is a laptop though and I find that this patch will somehow generate
lots of diskaccesses and thus the disk will never "sleep".
Checking out what the reason might be it seems like it is the preempt stuff
that
writes notes about processes been kicked ouf to /var/log/messages.
Is there a way to shut this off ?
BRGDS and thanks for the unified patch
--
Dag Nygren email: [email protected]
Oy Espoon NewTech Ab phone: +358 9 8024910
Tr?sktorpet 3 fax: +358 9 8024916
02360 ESBO Mobile: +358 400 426312
FINLAND
On Saturday 24 August 2002 08:33, [email protected] wrote:
> With the patch against 2.4.19:
>
> Scheduler O(1), Preemptible, Low Latency
>
> I have now added two extra alternative patches that include
> either Rik's rmap (thanks Rik) or AA's vm changes (thanks to Nuno Monteiro for
> merging this)
>
> For the record, with the (very) brief usage of these two patches I found the
> rmap patch a little faster. This is very subjective and completely untested.
Would you be so kind as to attempt to quantify that?
--
Daniel
Quoting Daniel Phillips <[email protected]>:
> Would you be so kind as to attempt to quantify that?
Ummm... I'm not sure if you're making fun or me? I haven't done any objective
tests so I can't quantify it ??
I just found the responsiveness of the machine a little better and don't have
the resources, time or inclination to test it with a benchmark. It's my
understanding that the -aa patch performed better on benchmarks, but that some
people reported the responsiveness was better with -rmap anyway. I'd agree with
the latter statement. I offer both patches with mine so if people want to try my
patch and feel strongly either way they can choose. My aim is to optimise system
response for single cpu desktops, not multi cpu servers.
Con.
On Saturday 24 August 2002 16:36, [email protected] wrote:
> Quoting Daniel Phillips <[email protected]>:
> > Would you be so kind as to attempt to quantify that?
>
> Ummm... I'm not sure if you're making fun or me? I haven't done any objective
> tests so I can't quantify it ??
Not at all. We need to quantify such results as yours, if we can.
> I just found the responsiveness of the machine a little better and don't have
> the resources, time or inclination to test it with a benchmark.
Fair enough.
> It's my
> understanding that the -aa patch performed better on benchmarks, but that some
> people reported the responsiveness was better with -rmap anyway. I'd agree with
> the latter statement. I offer both patches with mine so if people want to try my
> patch and feel strongly either way they can choose. My aim is to optimise system
> response for single cpu desktops, not multi cpu servers.
--
Daniel
On Sat, 24 Aug 2002 [email protected] wrote:
>
> With the patch against 2.4.19:
>
> Scheduler O(1), Preemptible, Low Latency
>
> I have now added two extra alternative patches that include
> either Rik's rmap (thanks Rik) or AA's vm changes (thanks to Nuno Monteiro for
> merging this)
>
> For the record, with the (very) brief usage of these two patches I found the
> rmap patch a little faster. This is very subjective and completely untested.
>
> Check them out here and tell me what you think(please read the FAQ):
> http://kernel.kolivas.net
I tried the 2.4.19-ck3-aa patch last night, and did a few informal tests
against my current production kernel, 2.4.19-ac4. Machine in Athlon
1400MHz, 1GB RAM, 20+30GB WD disks.
Kernel compile was about 7 sec faster with ck3-aa, 6:58 vs 7:05 (no -j
values).
Then I did my nightly backup of a scanned documentation project, making a
CD image from the scans, currently ~570MB. I was on ck3-aa, and I said
"self, that seemed pretty fast!" So I rebooted cold and tried the mkisofs
with both kernels, twice each.
2.4.19-ac4 2.4.19-ck3-aa
mkisofs 570MB 2:05 1:14
It was repeatably 40% faster! More testing, and now I'll build a stock
2.4.19 kernel for additional testing, and pull that responsiveness
benchmark and try that, too.
Looks like a nice job overall, I'm putting it on a laptop tonight, which
may give a better idea of how fast, or not, it really is.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Hi Bill,
> ...
> against my current production kernel, 2.4.19-ac4. Machine in Athlon
> 1400MHz, 1GB RAM, 20+30GB WD disks.
> ...
> Then I did my nightly backup of a scanned documentation project, making a
> CD image from the scans, currently ~570MB. I was on ck3-aa, and I said
> "self, that seemed pretty fast!" So I rebooted cold and tried the mkisofs
> with both kernels, twice each.
> 2.4.19-ac4 2.4.19-ck3-aa
> mkisofs 570MB 2:05 1:14
with WOLK v3.6 and only ONE harddisk drive:
root@codeman:[/] # du -skh /home
605M /home
root@codeman:[/] # find /home|wc -l
7384
root@codeman:[/] # time mkisofs -o /delme.iso -allow-multidot -iso-level 3 -J
-max-iso9660-filenames -U -R /home
...
real 1m12.872s
user 0m1.840s
sys 0m10.800s
with one big file:
root@codeman:[/] # du -skh /home/onebigfile.delme
620M /home
root@codeman:[/] # time mkisofs -o /delme.iso -allow-multidot -iso-level 3 -J
-max-iso9660-filenames -U -R /home/onebigfile.delme
...
real 0m35.676s
user 0m1.180s
sys 0m10.740s
:-)
Anyway, I also tested the patchset from Con, both, with -aa VM and -rmap VM
and I must say, -rmap is much slower than -aa VM.
Testmashine: Celeron 800MHz
256MB RAM
1x Seagate 30GB running in UDMA4 (ATA66) mode
Filesystem: ext3, data=ordered
I think with your mashine this could be a bit faster also ;)
--
Kind regards
Marc-Christian Petersen
http://sourceforge.net/projects/wolk
PGP/GnuPG Key: 1024D/569DE2E3DB441A16
Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16
Key available at http://www.keyserver.net. Encrypted e-mail preferred.
> Quoting Daniel Phillips <[email protected]>:
> > Would you be so kind as to attempt to quantify that?
>
> Ummm... I'm not sure if you're making fun or me? I haven't done any objective
> tests so I can't quantify it ??
>
> I just found the responsiveness of the machine a little better and don't have
> the resources, time or inclination to test it with a benchmark. It's my
> understanding that the -aa patch performed better on benchmarks, but that some
> people reported the responsiveness was better with -rmap anyway. I'd agree with
> the latter statement. I offer both patches with mine so if people want to try my
> patch and feel strongly either way they can choose. My aim is to optimise system
> response for single cpu desktops, not multi cpu servers.
>
> Con.
> -
> 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/
>
Con,
Thanks for the work, and nice web page!
To help with the testing, i have taken the liberty of adding your 2.4.19-ck3
patch to the OSDL's Patch
LifeCycle Manager. It's patch # 768. I've queued up a couple of the basic
tests against it, (dbench, dbt1 )
If you want to add future versions and get some testing run, see
http://osdl.org/cgi-bin/plm - it's really easy,
and you can use OSDL to make up for your lack of hardware. We do focus more
on multi-cpu systems, but
we're always interested in scheduler tests.
cliffw
On Sat, 24 Aug 2002 [email protected] wrote:
>
> With the patch against 2.4.19:
>
> Scheduler O(1), Preemptible, Low Latency
>
> I have now added two extra alternative patches that include
> either Rik's rmap (thanks Rik) or AA's vm changes (thanks to Nuno Monteiro for
> merging this)
>
> For the record, with the (very) brief usage of these two patches I found the
> rmap patch a little faster. This is very subjective and completely untested.
>
> Check them out here and tell me what you think(please read the FAQ):
> http://kernel.kolivas.net
The ck3-aa patch has worked perfectly for me until I try to shut down. At
that point I get to "turning off swap" and the system hangs with the disk
light on. Can't get a dump, and it doesn't happen every time, but enough
that I am very cautious in what I do at shutdown. Total hang ignoring
sysreq.
Athlon 1.4GHz, 1GB RAM, hda:30GB, hdc:40GB, 20x CD-R, multiple NICs, two
local networks, one PPP over high speed serial.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Quoting Bill Davidsen <[email protected]>:
> On Sat, 24 Aug 2002 [email protected] wrote:
> > With the patch against 2.4.19:
> > Scheduler O(1), Preemptible, Low Latency
> > I have now added two extra alternative patches that include
> > either Rik's rmap (thanks Rik) or AA's vm changes (thanks to Nuno Monteiro
> for
> > merging this)
> > For the record, with the (very) brief usage of these two patches I found
> the
> > rmap patch a little faster. This is very subjective and completely
> untested.
> > Check them out here and tell me what you think(please read the FAQ):
> > http://kernel.kolivas.net
>
> The ck3-aa patch has worked perfectly for me until I try to shut down. At
> that point I get to "turning off swap" and the system hangs with the disk
> light on. Can't get a dump, and it doesn't happen every time, but enough
> that I am very cautious in what I do at shutdown. Total hang ignoring
> sysreq.
>
> Athlon 1.4GHz, 1GB RAM, hda:30GB, hdc:40GB, 20x CD-R, multiple NICs, two
> local networks, one PPP over high speed serial.
Check on the website and you'll see that there have been two upgrades. The -ck5
patch now includes the -aa vm changes by default, and the hang on shutdown (due
to swapoff failing) has been fixed. For the record, the ck5 patch is the last
one until a new compressed cache patch becomes available for 2.4.19 and I will
merge that to make a -ck6 patch. The ck5 patch has proven to be very stable and
I am satisfied that it needs no further changes till the compressed cache patch
becomes available, so I recommend you upgrade to that.
Regards,
Con Kolivas.