-----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-----
On Friday 22 August 2003 23:41, Wiktor Wodecki wrote:
> On Fri, Aug 22, 2003 at 10:31:20PM +1000, Con Kolivas wrote:
> Content-Description: clearsigned data
>
> > -----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
>
> 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
On Fri, Aug 22, 2003 at 10:31:20PM +1000, Con Kolivas wrote:
Content-Description: clearsigned data
> -----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
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
On Fri, Aug 22, 2003 at 11:51:16PM +1000, Con Kolivas wrote:
> On Friday 22 August 2003 23:41, Wiktor Wodecki wrote:
> > On Fri, Aug 22, 2003 at 10:31:20PM +1000, Con Kolivas wrote:
> > Content-Description: clearsigned data
> >
> > > -----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
> >
> > 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.
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
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
On Saturday 23 August 2003 01:46, Wiktor Wodecki wrote:
> 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.
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
On Fri, Aug 22, 2003 at 03:41:37PM +0200, Wiktor Wodecki wrote:
> 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
What nice little utility is this from?
On Fri, Aug 22, 2003 at 11:35:50PM +0300, insecure wrote:
> On Friday 22 August 2003 20:53, Mike Fedyk wrote:
> > On Fri, Aug 22, 2003 at 03:41:37PM +0200, Wiktor Wodecki wrote:
> > > 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
> >
> > What nice little utility is this from?
>
> I'm curious too ;)
> I palyed a bit with a similar toy. Attached.
> Want to see other's source.
before more people email me, it's vmstat(8)
--
Regards,
Wiktor Wodecki
On Fri, Aug 22, 2003 at 10:44:33PM +0200, Wiktor Wodecki wrote:
> On Fri, Aug 22, 2003 at 11:35:50PM +0300, insecure wrote:
> > On Friday 22 August 2003 20:53, Mike Fedyk wrote:
> > > On Fri, Aug 22, 2003 at 03:41:37PM +0200, Wiktor Wodecki wrote:
> > > > 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
> > >
> > > What nice little utility is this from?
> >
> > I'm curious too ;)
> > I palyed a bit with a similar toy. Attached.
> > Want to see other's source.
>
> before more people email me, it's vmstat(8)
Unfortunately, the procps fork is getting even bigger now... :(
I don't see an option for this in debian's package.
On Fri, 2003-08-22 at 14:31, Con Kolivas wrote:
> -----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.
I have been using 2.6.0-test3-mm3 plus O18int for a whole day and I must
say that, for me, O18int is the best I've seen until date. I dare to say
I think it's even better than O10int.
Felipe Alfaro Solana wrote:
>I have been using 2.6.0-test3-mm3 plus O18int for a whole day and I must
>say that, for me, O18int is the best I've seen until date. I dare to say
>I think it's even better than O10int.
>
I'll second that, the priority inversion issues I was having with
2.6.0-test3-mm2 are completely gone! I haven't been able to get any
serious inversion issues to bring the system to its knees yet, but I'll
keep trying. The only difference is that I've disabled sound in order
to use the latest kernels, but I don't think that probably had anything
to do with the inversion problems I was running into.
And after using 2.6.0-test4 vanilla for a few hours I have a new
appreciation for the improvements that come with Con's patches...
-Wes-