login
Search
Con Kolivas [interview] has released O18int against 2.6.0-test3-mm3 (or O16.3), saying:
"Here is a small patchlet. It is possible tasks were getting more sleep_avg credit on requeuing than they could burn off while running so I've removed the on runqueue bonus to requeuing task."
From: Con Kolivas [email blocked] To: linux kernel mailing list [email blocked] Subject: [PATCH]O18int Date: Fri, 22 Aug 2003 22:31:20 +1000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is a small patchlet. It is possible tasks were getting more sleep_avg credit on requeuing than they could burn off while running so I've removed the on runqueue bonus to requeuing task. Note this applies onto O16.3 or 2.6.0-test3-mm3 as O17 was dropped. This patch is also available here along with a patch against 2.6.0-test3: http://kernel.kolivas.org/2.5 Con -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Rg0aZUg7+tp6mRURAhw+AJ9s3xwkNodB280E81VZnizvSRU0RQCghKT/ IN6uMO2E4heihDxjBE/JG7c= =5G4+ -----END PGP SIGNATURE-----
From: Wiktor Wodecki [email blocked] Subject: Re: [PATCH]O18int Date: Fri, 22 Aug 2003 15:41:37 +0200 this patch still makes my xmms skip on light io load (untar kernel source, open lkml mailbox folder) while opening mozilla. Even after mozilla is there xmms is still skipping. Processes take ages to spawn. And no, I'm not in swap. A 'su -'is taking 10 seconds to procceed. Same applies when rm -Rf'ing a kernel tree. Here is some more data for the curious: 15:38:55 cpu %usr %sys %nice %idle pswch/s runq nrproc lavg1 lavg5 avg15 _cpu_ 15:38:56 all 26 9 0 66 1730 3 115 11.58 7.87 3.44 15:38:57 all 8 4 0 88 1137 1 115 11.58 7.87 3.44 15:38:58 all 10 4 0 86 1204 1 115 11.58 7.87 3.44 15:38:59 all 6 5 0 89 1002 1 115 11.58 7.87 3.44 15:39:00 all 5 4 0 91 1219 1 115 11.58 7.87 3.44 15:39:01 all 9 4 0 87 1748 1 115 11.69 7.95 3.49 kakerlak:/home/wiktor# vmstat 1 100 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 4 8 0 2520 12644 103924 0 0 2325 665 1358 1803 22 8 11 60 0 10 0 2348 12608 103988 0 0 2208 1390 1436 1672 17 6 0 77 0 13 0 2532 12556 103728 0 0 1548 1153 1292 1138 9 4 0 87 0 6 0 2588 12564 103700 0 0 1516 1861 2039 1593 9 4 0 87 0 11 0 2420 12560 103756 0 0 840 817 1267 1339 5 4 0 91 0 10 0 2036 12608 104012 0 0 1248 941 1330 1879 10 6 0 84 0 8 0 17820 12620 103160 0 0 28 744 1260 1609 12 2 0 86 0 7 0 7448 12708 113636 0 0 8264 593 1418 2451 56 14 0 30 2 7 0 2116 12840 118912 0 0 3232 830 1649 3050 20 11 0 70 0 15 0 2364 12832 118380 0 0 452 822 1397 577 4 3 0 93 0 9 0 2564 12840 118176 0 0 1352 1076 1303 812 12 3 0 85 0 12 0 2692 12844 118004 0 0 1924 1252 1553 1200 18 3 0 79 note the load of 11. I can even get it to 30 while doing 3 tar xf bla.tar simultanously. I'm going to fetch some fish in the next two weeks in poland, so I will not be able to do any more testing from sunday on. Happy coding (while I stick to O10 *g*) -- Regards, Wiktor Wodecki
From: Con Kolivas [email blocked] Subject: Re: [PATCH]O18int Date: Fri, 22 Aug 2003 23:51:16 +1000 On Friday 22 August 2003 23:41, Wiktor Wodecki wrote: > this patch still makes my xmms skip on light io load (untar kernel > source, open lkml mailbox folder) while opening mozilla. Even after > mozilla is there xmms is still skipping. Processes take ages to spawn. > And no, I'm not in swap. A 'su -'is taking 10 seconds to procceed. > Same applies when rm -Rf'ing a kernel tree. > Here is some more data for the curious: > note the load of 11. I can even get it to 30 while doing 3 tar xf > bla.tar simultanously. Complete mystery. > > I'm going to fetch some fish in the next two weeks in poland, so I will > not be able to do any more testing from sunday on. Happy coding (while I > stick to O10 *g*) Thanks for comments. ] There it is again; the reference to darn O10. Hrm. One question before your holiday; your O10 kernel is it the same kernel tree or a different/newere one? I'm looking to blame something else here I know but I need to know; this just doesn't hold with any testing here. Con
From: Wiktor Wodecki [email blocked] Subject: Re: [PATCH]O18int Date: Fri, 22 Aug 2003 16:56:23 +0200 On Fri, Aug 22, 2003 at 11:51:16PM +1000, Con Kolivas wrote: > There it is again; the reference to darn O10. Hrm. One question before your > holiday; your O10 kernel is it the same kernel tree or a different/newere > one? I'm looking to blame something else here I know but I need to know; this > just doesn't hold with any testing here. well, I run O10 on top of test2, since I didn't need any patches from test3 I didn't rediff it. -- Regards, Wiktor Wodecki
From: Wiktor Wodecki [email blocked] Subject: Re: [PATCH]O18int Date: Fri, 22 Aug 2003 17:46:39 +0200 On Sat, Aug 23, 2003 at 01:03:19AM +1000, Con Kolivas wrote: > > > There it is again; the reference to darn O10. Hrm. One question before > > > your holiday; your O10 kernel is it the same kernel tree or a > > > different/newere one? I'm looking to blame something else here I know but > > > I need to know; this just doesn't hold with any testing here. > > > > well, I run O10 on top of test2, since I didn't need any patches from > > test3 I didn't rediff it. > > So O18 is also on test2? Okay, I applied O18 on top of test2 now. Xmms works as a charm, programm start is still slow while doing an tar xf linuxtest2.tar. Already open xterm's (one with mutt) react a bit in-interactive (I spawn vi to write this email and a :w takes 5 seconds). It is nonetheless worse than O10, sorry to say that. -- Regards, Wiktor Wodecki
From: Con Kolivas [email blocked] Subject: Re: [PATCH]O18int Date: Sat, 23 Aug 2003 01:54:36 +1000 On Saturday 23 August 2003 01:46, Wiktor Wodecki wrote: > Okay, I applied O18 on top of test2 now. Xmms works as a charm, > programm start is still slow while doing an tar xf linuxtest2.tar. > Already open xterm's (one with mutt) react a bit in-interactive (I spawn > vi to write this email and a :w takes 5 seconds). It is nonetheless > worse than O10, sorry to say that. Ok, but none of that weird starvation and massive load and skipping audio. Interesting. At least it's clear now that all is _not_ just my patches. Thanks for testing. Con
