patch-O1int-0306302317 for 2.5.73 interactivity
Subsystems (3)
PATCH 1/1 patch-O1int-0306302317 for 2.5.73 interactivity
Buried deep in another mail thread was the latest implementation of my O1int patch so I've brought it to the surface to make it clear this one is significantly different from past iterations.
Summary:
Decreases audio skipping with loads.
Smooths out X performance with load.
I've also made it available here:
http://kernel.kolivas.org/2.5
along with a patch called granularity that is a modified version of Ingo's timeslice_granularity patch. It is no longer necessary and may slightly decrease throughput in non-desktop settings but put on top of my O1int patch makes X even smoother.
Con
kernel/sched.c +33 -18
@@ -314,11 +314,23 @@ static inline void enqueue_task(struct tstatic int effective_prio (task_t *p) {int bonus, prio; +long sleep_period;if (rt_task (p))return p->prio; - bonus =MAX_USER_PRIO *PRIO_BONUS_RATIO *p->sleep_avg/MAX_SLEEP_AVG /100 - + sleep_period = jiffies - p->avg_start; + +if (!sleep_period) +return p->static_prio; + +if (sleep_period >MAX_SLEEP_AVG ) + sleep_period =MAX_SLEEP_AVG ; + +if (p->sleep_avg > sleep_period) + sleep_period = p->sleep_avg; + + bonus =MAX_USER_PRIO *PRIO_BONUS_RATIO *p->sleep_avg/sleep_period/100 -MAX_USER_PRIO *PRIO_BONUS_RATIO /100 /2 ; prio = p->static_prio - bonus;
@@ -348,9 +360,19 @@ static inline void activate_task(task_t {long sleep_time = jiffies - p->last_run -1 ; -if (sleep_time >0 ) { -int sleep_avg; +if (p->avg_start ==0 ){ + p->avg_start = jiffies; + p->sleep_avg =0 ; + sleep_time =0 ; + } +if (sleep_time >=0 ) { + +if (sleep_time >HZ ){ + p->avg_start = jiffies; + p->sleep_avg =0 ; + } +else {/* * This code gives a bonus to interactive tasks. *
@@ -359,7 +381,7 @@ static inline void activate_task(task_t* spends sleeping, the higher the average gets - and the * higher the priority boost gets as well. */ - sleep_avg = p->sleep_avg + sleep_time; + p->sleep_avg += sleep_time;/* * 'Overflow' bonus ticks go to the waker as well, so the
@@ -367,12 +389,14 @@ static inline void activate_task(task_t* boosting tasks that are related to maximum-interactive * tasks. */ -if (sleep_avg >MAX_SLEEP_AVG ) - sleep_avg =MAX_SLEEP_AVG ; -if (p->sleep_avg != sleep_avg) { - p->sleep_avg = sleep_avg; - p->prio =effective_prio (p); +if (p->sleep_avg >MAX_SLEEP_AVG *12 /10 ) + p->sleep_avg =MAX_SLEEP_AVG *11 /10 ; + } +if (unlikely (p->avg_start > jiffies)){ + p->avg_start = jiffies; + p->sleep_avg =0 ; } + p->prio =effective_prio (p); }__activate_task (p, rq); }
@@ -549,8 +573,6 @@ void wake_up_forked_process(task_t * p)* and children as well, to keep max-interactive tasks * from forking tasks that are max-interactive. */ - current->sleep_avg = current->sleep_avg *PARENT_PENALTY /100 ; - p->sleep_avg = p->sleep_avg *CHILD_PENALTY /100 ; p->prio =effective_prio (p);set_task_cpu (p,smp_processor_id ());
@@ -586,13 +608,6 @@ void sched_exit(task_t * p) p->parent->time_slice =MAX_TIMESLICE ; }local_irq_restore (flags); -/* -* If the child was a (relative-) CPU hog then decrease -* the sleep_avg of the parent as well. -*/ -if (p->sleep_avg < p->parent->sleep_avg) - p->parent->sleep_avg = (p->parent->sleep_avg *EXIT_WEIGHT + - p->sleep_avg) / (EXIT_WEIGHT +1 ); }/**
kernel/fork.c +1 -0
@@ -863,6 +863,7 @@ struct task_struct *copy_process(unsigne p->array =NULL ; p->lock_depth =-1 ;/* -1 = no lock */ p->start_time =get_jiffies_64 (); + p->avg_start =0 ; p->security =NULL ; retval = -ENOMEM ;
include/linux/sched.h +1 -0
@@ -336,6 +336,7 @@ struct task_struct {prio_array_t *array;unsigned long sleep_avg; +unsigned long avg_start;unsigned long last_run;unsigned long policy;
Quoted 7 lines · Con Kolivas
Buried deep in another mail thread was the latest implementation of my O1int patch so I've brought it to the surface to make it clear this one is significantly different from past iterations.
Summary:
Decreases audio skipping with loads.
Smooths out X performance with load.
I tried this with normal developer box type load on a slow box ie;
2x 400MHz 512MB source/build fs' on UW2 SCSI
kernel: 2.5.72-mm3
2x make -j2 bzImage
bk pull (linux-2.5 repo)
cvs import of 2.5 tree
navigating bk revtool (this normally causes pauses) read disk benchmark just to thrash IDE about a bit ;)
Still a few MP3 pauses (due to bk revtool mainly) but mouse/keyboard response was good, there is however a vast improvement over 2.5.73 stock (2-5s pauses with no keyboard/mouse response) for my particular workload.
zwane@montezuma ~ {0:0} uptime
14:18:06 up 54 min, 25 users, load average: 7.33, 6.58, 5.59
zwane@montezuma ~ {0:0} vmstat 1
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id 3 3 1 27444 3628 4012 108068 4 11 5837 1680 841 994 58 22 20 1 5 0 27428 4920 8184 107924 8 0 11292 948 1551 3081 49 51 0 3 3 1 27432 3832 7764 107664 0 8 13084 1440 1503 2192 52 45 3 1 5 0 27432 14552 20992 83772 332 0 16320 844 1632 2721 56 44 0 0 6 0 24500 15568 31548 91088 224 0 17160 0 1552 2423 67 33 0 2 4 1 24504 2916 33428 96788 32 0 21912 580 1703 2969 62 38 0 4 2 2 24508 3284 25688 98812 0 4 23248 2164 1575 2507 74 26 0 2 4 1 24512 2780 18984 103752 0 8 22412 796 1606 2693 76 24 0 6 2 0 24516 4012 13324 107712 0 4 20224 1604 1738 2916 69 31 0 6 1 1 24528 2196 14836 108172 0 8 20188 2472 2260 4051 58 42 0
Signature · 1 line
function.linuxpower.ca
Quoted 20 lines · Zwane Mwaikambo
Quoted 7 lines · Con Kolivas
Buried deep in another mail thread was the latest implementation of my O1int patch so I've brought it to the surface to make it clear this one is significantly different from past iterations.
Summary:
Decreases audio skipping with loads.
Smooths out X performance with load.I tried this with normal developer box type load on a slow box ie;
2x 400MHz 512MB source/build fs' on UW2 SCSI
kernel: 2.5.72-mm32x make -j2 bzImage
bk pull (linux-2.5 repo)
cvs import of 2.5 tree
navigating bk revtool (this normally causes pauses) read disk benchmark just to thrash IDE about a bit ;)
Quoted 4 lines
Still a few MP3 pauses (due to bk revtool mainly) but mouse/keyboard response was good, there is however a vast improvement over 2.5.73 stock (2-5s pauses with no keyboard/mouse response) for my particular workload.
Thanks for testing and working with me.
Please if others are testing and still having problems note this work is _not_ complete yet, but I do need to assess every incremental change to make sure it addresses the issue I am trying to fix at each step.
For what it's worth there are still at least 3 things I need to implement/change in this patch which induce problems still, so tell me of your experiences and I will try hard to accomodate.
Con
Quoted 8 lines · Con Kolivas
Buried deep in another mail thread was the latest implementation of my O1int patch so I've brought it to the surface to make it clear this one is significantly different from past iterations.
Summary:
Decreases audio skipping with loads.
Smooths out X performance with load.
Quoted 7 lines
I've also made it available here:
http://kernel.kolivas.org/2.5along with a patch called granularity that is a modified version of Ingo's
timeslice_granularitypatch. It is no longer necessary and may slightly decrease throughput in non-desktop settings but put on top of my O1int patch makes X even smoother.
Damn! XMMS audio skips are back... To reproduce them, I start up my KDE session, launch Konqueror, launch XMMS and make it play sound. Then, I drag the Konqueror window like crazy over my desktop and XMMS skips, altough not too much.
The previous version of this patch is the one that worked best for me.
Quoted 17 lines · Felipe Alfaro Solana
Quoted 8 lines · Con Kolivas
Buried deep in another mail thread was the latest implementation of my O1int patch so I've brought it to the surface to make it clear this one is significantly different from past iterations.
Summary:
Decreases audio skipping with loads.
Smooths out X performance with load.Quoted 7 lines
I've also made it available here:
http://kernel.kolivas.org/2.5along with a patch called granularity that is a modified version of Ingo's
timeslice_granularitypatch. It is no longer necessary and may slightly decrease throughput in non-desktop settings but put on top of my O1int patch makes X even smoother.
Quoted 6 lines
Damn! XMMS audio skips are back... To reproduce them, I start up my KDE session, launch Konqueror, launch XMMS and make it play sound. Then, I drag the Konqueror window like crazy over my desktop and XMMS skips, altough not too much.
The previous version of this patch is the one that worked best for me.
A little bit more of this.. a little bit less of that... Use 100 or 1000Hz for this one? And did you notice any change in X?
Con
Quoted 23 lines · Con Kolivas
Quoted 22 lines · Felipe Alfaro Solana
Quoted 8 lines · Con Kolivas
Buried deep in another mail thread was the latest implementation of my O1int patch so I've brought it to the surface to make it clear this one is significantly different from past iterations.
Summary:
Decreases audio skipping with loads.
Smooths out X performance with load.Quoted 7 lines
I've also made it available here:
http://kernel.kolivas.org/2.5along with a patch called granularity that is a modified version of Ingo's
timeslice_granularitypatch. It is no longer necessary and may slightly decrease throughput in non-desktop settings but put on top of my O1int patch makes X even smoother.Damn! XMMS audio skips are back... To reproduce them, I start up my KDE session, launch Konqueror, launch XMMS and make it play sound. Then, I drag the Konqueror window like crazy over my desktop and XMMS skips, altough not too much.
Quoted 4 lines
Quoted 1 line
The previous version of this patch is the one that worked best for me.
A little bit more of this.. a little bit less of that... Use 100 or 1000Hz for this one? And did you notice any change in X?
I'm using 1000HZ. With respect to X, I haven't noticed any major difference. Should I? I haven't tested it under very heavy loads, but under normal workloads, it behaves a little better than its predecesors.
Quoted 24 lines · Felipe Alfaro Solana
Quoted 23 lines · Con Kolivas
Quoted 22 lines · Felipe Alfaro Solana
Quoted 8 lines · Con Kolivas
Buried deep in another mail thread was the latest implementation of my O1int patch so I've brought it to the surface to make it clear this one is significantly different from past iterations.
Summary:
Decreases audio skipping with loads.
Smooths out X performance with load.Quoted 7 lines
I've also made it available here:
http://kernel.kolivas.org/2.5along with a patch called granularity that is a modified version of Ingo's
timeslice_granularitypatch. It is no longer necessary and may slightly decrease throughput in non-desktop settings but put on top of my O1int patch makes X even smoother.Damn! XMMS audio skips are back... To reproduce them, I start up my KDE session, launch Konqueror, launch XMMS and make it play sound. Then, I drag the Konqueror window like crazy over my desktop and XMMS skips, altough not too much.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
The previous version of this patch is the one that worked best for me.
A little bit more of this.. a little bit less of that... Use 100 or 1000Hz for this one? And did you notice any change in X?
I'm using 1000HZ. With respect to X, I haven't noticed any major difference. Should I? I haven't tested it under very heavy loads, but under normal workloads, it behaves a little better than its predecesors.
I'd say it would depend on the graphic card. On a sis630 even with a p3 1133 it is embarassingly jerky under even the slightest of loads without my patch. However, it is as good now without the granularity patch as earlier with the granularity.
Con
Quoted 9 lines · Con Kolivas
Quoted 3 lines · Felipe Alfaro Solana
I'm using 1000HZ. With respect to X, I haven't noticed any major difference. Should I? I haven't tested it under very heavy loads, but under normal workloads, it behaves a little better than its predecesors.
I'd say it would depend on the graphic card. On a sis630 even with a p3 1133 it is embarassingly jerky under even the slightest of loads without my patch. However, it is as good now without the granularity patch as earlier with the granularity.
When I say "X feels jerky", I mean that I can notice the scheduler is not giving the X server enough CPU cycles (I mean, a continuous, smaller, but more frequent CPU timeslice) to perform window movement and redrawing fast enough to get ~25fps. Also, I don't think it's related to the video card. The combo patch I did with Mike's + Ingo's enhacements works beautifully for me.
Quoted 12 lines · Con Kolivas
Quoted 9 lines · Felipe Alfaro Solana
Quoted 3 lines
I'm using 1000HZ. With respect to X, I haven't noticed any major difference. Should I? I haven't tested it under very heavy loads, but under normal workloads, it behaves a little better than its predecesors.
I'd say it would depend on the graphic card. On a sis630 even with a p3 1133 it is embarassingly jerky under even the slightest of loads without my patch. However, it is as good now without the granularity patch as earlier with the granularity.
Quoted 6 lines
When I say "X feels jerky", I mean that I can notice the scheduler is not giving the X server enough CPU cycles (I mean, a continuous, smaller, but more frequent CPU timeslice) to perform window movement and redrawing fast enough to get ~25fps. Also, I don't think it's related to the video card. The combo patch I did with Mike's + Ingo's enhacements works beautifully for me.
Actually just the bastardised Ingo patch will do that on it's own. However that's never going to be incorporated.
Con
Quoted 9 lines · Con Kolivas
Quoted 6 lines
When I say "X feels jerky", I mean that I can notice the scheduler is not giving the X server enough CPU cycles (I mean, a continuous, smaller, but more frequent CPU timeslice) to perform window movement and redrawing fast enough to get ~25fps. Also, I don't think it's related to the video card. The combo patch I did with Mike's + Ingo's enhacements works beautifully for me.
Actually just the bastardised Ingo patch will do that on it's own. However that's never going to be incorporated.
So, I guess we won't have the option to choose between different CPU schedulers (desktop or server, for example), like we have in -mm kernels with IO schedulers (deadline or anticipatory).
Seriously talking, I prefer to have the best performance in my server boxes, but for my laptop, I prefer shorter timeslices, lower peformance and better turnaround times and a wiser CPU scheduler. Just my two cents.
It's sad to say but I feel the vanilla 2.5 CPU scheduler doesn't match my end-user preferences :-(
Quoted 15 lines · Felipe Alfaro Solana
Quoted 9 lines · Con Kolivas
Quoted 6 lines
When I say "X feels jerky", I mean that I can notice the scheduler is not giving the X server enough CPU cycles (I mean, a continuous, smaller, but more frequent CPU timeslice) to perform window movement and redrawing fast enough to get ~25fps. Also, I don't think it's related to the video card. The combo patch I did with Mike's + Ingo's enhacements works beautifully for me.
Actually just the bastardised Ingo patch will do that on it's own. However that's never going to be incorporated.
So, I guess we won't have the option to choose between different CPU schedulers (desktop or server, for example), like we have in -mm kernels with IO schedulers (deadline or anticipatory).
Quoted 7 lines
Seriously talking, I prefer to have the best performance in my server boxes, but for my laptop, I prefer shorter timeslices, lower peformance and better turnaround times and a wiser CPU scheduler. Just my two cents.
It's sad to say but I feel the vanilla 2.5 CPU scheduler doesn't match my end-user preferences :-(
There will always be alternate trees. Whether options like this make it into mainline will be up to the maintainer of course, but given that we seem to have a "swappiness" dial in mainline then I suspect we may have more dials in 2.6 than before.
Con
Quoted 21 lines · Con Kolivas
Quoted 20 lines · Felipe Alfaro Solana
Quoted 9 lines · Con Kolivas
Quoted 6 lines
When I say "X feels jerky", I mean that I can notice the scheduler is not giving the X server enough CPU cycles (I mean, a continuous, smaller, but more frequent CPU timeslice) to perform window movement and redrawing fast enough to get ~25fps. Also, I don't think it's related to the video card. The combo patch I did with Mike's + Ingo's enhacements works beautifully for me.
Actually just the bastardised Ingo patch will do that on it's own. However that's never going to be incorporated.
So, I guess we won't have the option to choose between different CPU schedulers (desktop or server, for example), like we have in -mm kernels with IO schedulers (deadline or anticipatory).
Seriously talking, I prefer to have the best performance in my server boxes, but for my laptop, I prefer shorter timeslices, lower peformance and better turnaround times and a wiser CPU scheduler. Just my two cents.
Quoted 7 lines
Quoted 2 lines
It's sad to say but I feel the vanilla 2.5 CPU scheduler doesn't match my end-user preferences :-(
There will always be alternate trees. Whether options like this make it into mainline will be up to the maintainer of course, but given that we seem to have a "swappiness" dial in mainline then I suspect we may have more dials in 2.6 than before.
I don't like knobs at all [1], but I have to ~agree with Felipe.
A prime candidate for a knob (rather switch) would be a slightly more sane back-boost for desktop use. I'm playing with back-boost in my tree, allowing a limited quantity, and strictly from user tasks... it helps the desktop quite a bit. Another thing that's very important for the desktop (and shell) is startup time for new tasks. I'm working on something there too (works great when it's not busy breaking everything to pieces;). Modulo me ever getting that darn thing working acceptably well, another candidate is to either export CHILD_PENALTY as in scheduler knobs patch, or just set it to ~75-~85 when back-boost is enabled, ie make one desktop mode switch and hope like heck it doesn't cause more trouble than it's worth.
-Mike
1. Dear LKML, why does performance suck? My .config and 10000 random knob settings attached.
Hello,
I'm running this patch for a couple of hours and it is worse than the plain 2.5.73-bk7. It doesn't hang exactly (and I didn't listen to any music, yet) but during normal work (switching x-screens, scrolling in browser, pressing keys, etc.) the systems hangs non-deterministically for maybe half a second or so. For example, when I typed this sentence I noticed that pressing the backspace key didn't trigger anything for a while and then it continued with the sentence (correctly, tho). I cannot reproduce it and the machine is doing virtually nothing. Please tell me if you need more information.
Quoted 8 lines · Con Kolivas
Buried deep in another mail thread was the latest implementation of my O1int
patch so I've brought it to the surface to make it clear this one is significantly different from past iterations.Summary:
Decreases audio skipping with loads.
Smooths out X performance with load.
Signature · 3 lines
Regards, Wiktor Wodecki