Skip to contentSkip to conversation

O18int

PATCH In review Con Kolivas 5 participants 11 messages Aug 22, 2003 – Aug 27, 2003 2 messages not in the archive

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 O18int

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

kernel/sched.c +0 -6
@@ -1418,12 +1418,6 @@ void scheduler_tick(int user_ticks, int 
 
 			dequeue_task(p, rq->active);
 			set_tsk_need_resched(p);
-			/*
-			 * Tasks with interactive credit get all their
-			 * time waiting on the run queue credited as sleep
-			 */
-			if (HIGH_CREDIT(p))
-				p->activated = 2;
 			p->prio = effective_prio(p);
 			enqueue_task(p, rq->active);
 		}
#1 lore raw

On Fri, Aug 22, 2003 at 10:31:20PM +1000, Con Kolivas wrote:
Content-Description: clearsigned data

Quoted 9 lines

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

Quoted 6 lines

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*)

Signature · 3 lines
Regards,

Wiktor Wodecki
#2 lore raw
Quoted 26 lines · Wiktor Wodecki

On Fri, Aug 22, 2003 at 10:31:20PM +1000, Con Kolivas wrote:
Content-Description: clearsigned data

Quoted 9 lines

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

Quoted 6 lines

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:

Quoted 2 lines

note the load of 11. I can even get it to 30 while doing 3 tar xf bla.tar simultanously.

Complete mystery.

Quoted 4 lines

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

#3 lore raw
Quoted 36 lines · Con Kolivas
Quoted 26 lines · Wiktor Wodecki

On Fri, Aug 22, 2003 at 10:31:20PM +1000, Con Kolivas wrote:
Content-Description: clearsigned data

Quoted 9 lines

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

Quoted 6 lines

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:

Quoted 2 lines

note the load of 11. I can even get it to 30 while doing 3 tar xf bla.tar simultanously.

Complete mystery.

Quoted 4 lines

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*)

Quoted 6 lines

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.

Signature · 3 lines
Regards,

Wiktor Wodecki

A message that is not in the archive (sent off-list or not yet received): [email protected]

#5 lore raw
Quoted 9 lines · Con Kolivas
Quoted 7 lines
Quoted 4 lines

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.

Signature · 3 lines
Regards,

Wiktor Wodecki
#6 lore raw
Quoted 9 lines · Wiktor Wodecki
Quoted 8 lines · Con Kolivas
Quoted 7 lines
Quoted 4 lines

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.

Quoted 7 lines
Quoted 1 line

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

#7 lore raw
In reply to Wiktor Wodecki
Quoted 7 lines · Wiktor Wodecki
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?

A message that is not in the archive (sent off-list or not yet received): [email protected]

#9 lore raw
Quoted 11 lines · insecure
Quoted 10 lines · Mike Fedyk
Quoted 8 lines · Wiktor Wodecki

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

Quoted 5 lines
Quoted 1 line

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)

Signature · 3 lines
Regards,

Wiktor Wodecki
#10 lore raw
Quoted 12 lines · Wiktor Wodecki
Quoted 11 lines · insecure
Quoted 10 lines · Mike Fedyk
Quoted 8 lines · Wiktor Wodecki

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

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

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.

#11 lore raw
In reply to Con Kolivas
Quoted 8 lines · Con Kolivas

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

#12 lore raw
Quoted 4 lines · Felipe Alfaro Solana

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-