patch-O1int-0306281420 for 2.5.73 interactivity
Subsystems (3)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
For my sins I've included what I thought was necessary for this patch.
The interactivity for tasks is based on the sleep avg accumulated divided by the running time of the task. However since the accumulated time is not linear with time it now works on the premise that running time is an exponential function entirely. Pat Erley was the genius who implemented this simple exponential function in surprisingly low overhead integer maths.
Also added was some jiffy wrap logic (as if anyone would still be running my patch in 50 days :P).
Long sleepers were reclassified as idle according to the new exponential logic.
If you test, please note this works better at 1000Hz.
Attached also is my bastardised version of Ingo's timeslice granularity patch. This round robins tasks on the active array every 10ms, which _might_ be detrimental in throughput applications but has not been benchmarked. However for desktops it does wonders to smoothing out the jerkiness of X and I highly recommend using this in combination with the O1int patch.
This is very close to all the logic I wanted to implement. It might need more tuning... Note parent penalty, child penalty and exit weight (uppercase) no longer do anything.
Please test and comment.
Con
P.S. In the words of Zwane - there is always a corner case. Corner case I think I still need to tackle is the application that spins madly waiting for it's child to start, and in the process it is the parent that is starving the child by being higher priority than it. This seems to be a coding style anomaly brought out by the scheduler.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE+/SSSF6dfvkL3i1gRArK1AJ93sHl+I8J0qaOesShdJLvU1YENPgCglJhv mxFcs8sAun1QNw0gz2tLJ2Q=
=S5PH
-----END PGP SIGNATURE-----
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;
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 = jiffies; p->security =NULL ; retval = -ENOMEM ;
kernel/sched.c +32 -17
91 lines not on this page · raw message
kernel/sched.c +9 -0
@@ -1229,7 +1229,16 @@ void scheduler_tick(int user_ticks, intenqueue_task (p, rq->expired); }else enqueue_task (p, rq->active); + }else { +if (!(p->time_slice %MIN_TIMESLICE ) && + (p->array == rq->active)) { +dequeue_task (p, rq->active); +set_tsk_need_resched (p); + p->prio =effective_prio (p); +enqueue_task (p, rq->active); + } } + out_unlock:spin_unlock (&rq->lock); out:
Quoted 30 lines · Con Kolivas
For my sins I've included what I thought was necessary for this patch.
The interactivity for tasks is based on the sleep avg accumulated divided by the running time of the task. However since the accumulated time is not linear with time it now works on the premise that running time is an exponential function entirely. Pat Erley was the genius who implemented this simple exponential function in surprisingly low overhead integer maths.
Also added was some jiffy wrap logic (as if anyone would still be running my patch in 50 days :P).
Long sleepers were reclassified as idle according to the new exponential logic.
If you test, please note this works better at 1000Hz.
Attached also is my bastardised version of Ingo's timeslice granularity patch. This round robins tasks on the active array every 10ms, which _might_ be detrimental in throughput applications but has not been benchmarked. However for desktops it does wonders to smoothing out the jerkiness of X and I highly recommend using this in combination with the O1int patch.
This is very close to all the logic I wanted to implement. It might need more tuning... Note parent penalty, child penalty and exit weight (uppercase) no longer do anything.
Please test and comment.
Quoted 7 lines
Con
P.S. In the words of Zwane - there is always a corner case. Corner case I think I still need to tackle is the application that spins madly waiting for it's child to start, and in the process it is the parent that is starving the child by being higher priority than it. This seems to be a coding style anomaly brought out by the scheduler.
And just for good measure here is the latest with a slight addition that helps X smoothness over time. It gives the sleep_avg a little headroom so it doesn't drop from interactive as easily with bursts of cpu activity.
Con
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;
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 = jiffies; p->security =NULL ; retval = -ENOMEM ;
kernel/sched.c +32 -17
91 lines not on this page · raw message
Quoted 6 lines · Con Kolivas
Quoted 2 lines · Con Kolivas
For my sins I've included what I thought was necessary for this patch.
And just for good measure here is the latest with a slight addition that helps X smoothness over time. It gives the
sleep_avga little headroom so it doesn't drop from interactive as easily with bursts of cpu activity.
Have not tried this one, but previous had the same issues on this HT box. Reverted the two patches, and I have no mouse jerkyness or laggy redraw of windows.
Anyhow, will it be a wise move to try and get a scheduler that works fine for both UP and SMP ?
Regards,
Signature · 1 line
Martin Schlemmer
Quoted 8 lines · Martin Schlemmer
Quoted 6 lines · Con Kolivas
Quoted 1 line · Con Kolivas
For my sins I've included what I thought was necessary for this patch.
And just for good measure here is the latest with a slight addition that helps X smoothness over time. It gives the
sleep_avga little headroom so it doesn't drop from interactive as easily with bursts of cpu activity.
Quoted 6 lines
Have not tried this one, but previous had the same issues on this HT box. Reverted the two patches, and I have no mouse jerkyness or laggy redraw of windows.
Anyhow, will it be a wise move to try and get a scheduler that works fine for both UP and SMP ?
Indeed. I wasn't trying to make a UP only patch, and it was not finished (nothing ever is really).
Con
Quoted 39 lines · Con Kolivas
Quoted 30 lines · Con Kolivas
For my sins I've included what I thought was necessary for this patch.
The interactivity for tasks is based on the sleep avg accumulated divided by the running time of the task. However since the accumulated time is not linear with time it now works on the premise that running time is an exponential function entirely. Pat Erley was the genius who implemented this simple exponential function in surprisingly low overhead integer maths.
Also added was some jiffy wrap logic (as if anyone would still be running my patch in 50 days :P).
Long sleepers were reclassified as idle according to the new exponential logic.
If you test, please note this works better at 1000Hz.
Attached also is my bastardised version of Ingo's timeslice granularity patch. This round robins tasks on the active array every 10ms, which _might_ be detrimental in throughput applications but has not been benchmarked. However for desktops it does wonders to smoothing out the jerkiness of X and I highly recommend using this in combination with the O1int patch.
This is very close to all the logic I wanted to implement. It might need more tuning... Note parent penalty, child penalty and exit weight (uppercase) no longer do anything.
Please test and comment.
Quoted 7 lines
Con
P.S. In the words of Zwane - there is always a corner case. Corner case I think I still need to tackle is the application that spins madly waiting for it's child to start, and in the process it is the parent that is starving the child by being higher priority than it. This seems to be a coding style anomaly brought out by the scheduler.
Quoted 3 lines
And just for good measure here is the latest with a slight addition that helps X smoothness over time. It gives the
sleep_avga little headroom so it doesn't drop from interactive as easily with bursts of cpu activity.
OK, now testing this one :-)
2.5.73-mm2 + latest patch-O1int + patch-granularity + 1000HZ... Feels a little bit better than the previous one. X under load is smoother. This is starting to get interesting ;-)
Quoted 6 lines · Con Kolivas
The interactivity for tasks is based on the sleep avg accumulated divided by the running time of the task. However since the accumulated time is not linear with time it now works on the premise that running time is an exponential function entirely. Pat Erley was the genius who implemented this simple exponential function in surprisingly low overhead integer maths.
Quoted 7 lines
Also added was some jiffy wrap logic (as if anyone would still be running my patch in 50 days :P).
Long sleepers were reclassified as idle according to the new exponential logic.
If you test, please note this works better at 1000Hz.
Currently testing on 2.5.73-mm2, with both patches (patch-O1int and patch-granularity) plus HZ=1000. The result is quite impressive. Under load, X still suffer a little lag and behaves a little worse than the combo patch from Mike Galbraith + Ingo, but now XMMS doesn't skip even when clicking a link inside Evolution.
Please, let me more time to work with this new patched kernel a little bit more to see if I can find any strange issues.
I made a small error when I sent Con a piece of magic I wrote up to help the sleep period.
what it says right now:
/kernel/sched.c around line 325
sleep_period = (sleep_period *
17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));
----------------------------------------------------------^
it should be:
sleep_period = (sleep_period *
17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));
--------------------------------------------------------------^
stupid parenthesis.
a little background. what this essentially is is a taylor approximation of the function ln(66x+1) normalized. ln(66x+1) happens to do a great job oas a weighting function on the range of 0 to 1, and because the input only happens to range from 0 to 1, only 2 terms were needed to do a 'good enough' job.
Pat
Quoted 14 lines · pat erley
I made a small error when I sent Con a piece of magic I wrote up to help the sleep period.
what it says right now:
/kernel/sched.c around line 325
sleep_period= (sleep_period*17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));----------------------------------------------------------^
it should be:
sleep_period= (sleep_period*
Quoted 8 lines
17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));--------------------------------------------------------------^
stupid parenthesis.
a little background. what this essentially is is a taylor approximation of the function ln(66x+1) normalized. ln(66x+1) happens to do a great job oas a weighting function on the range of 0 to 1, and because the input only happens to range from 0 to 1, only 2 terms were needed to do a 'good enough' job.
Pat
I did your correction and I got a kernel panic(attempting to kill init) on boot. It didn't flushed to disk, so it isn't attached, but it panics at effective_prio+0xcc/0xe0.
With objdump I could see it traps a division by 0:
cc: f7 fb idiv %ebx
I remember cleary %ebx being 0 on the panic report.
And I tracked down and the code is on this else in effective_prio:
----------- sched.c 341-----------------
else {
sleep_period = (sleep_period *
17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));
if (!sleep_period)
return p->static_prio;
}--------------------------------------
I don't have the time now to track this further today, but what happens if sleep_period is too small and tau is too big?
Could this (17 * sleep_period / (5 * tau + 2) give 0 and so a division
by 0?
abs
Roberto
Quoted 44 lines · Roberto Orenstein
Quoted 20 lines · pat erley
I made a small error when I sent Con a piece of magic I wrote up to help the sleep period.
what it says right now:
/kernel/sched.c around line 325
sleep_period= (sleep_period*17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));----------------------------------------------------------^
it should be:
sleep_period= (sleep_period*17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));--------------------------------------------------------------^
stupid parenthesis.
Quoted 7 lines
a little background. what this essentially is is a taylor approximation of the function ln(66x+1) normalized. ln(66x+1) happens to do a great job oas a weighting function on the range of 0 to 1, and because the input only happens to range from 0 to 1, only 2 terms were needed to do a 'good enough' job.
Pat
I did your correction and I got a kernel panic(attempting to kill init) on boot. It didn't flushed to disk, so it isn't attached, but it panics at
effective_prio+0xcc/0xe0.
With objdump I could see it traps a division by 0:
cc: f7 fb idiv %ebxI remember cleary %ebx being 0 on the panic report.
And I tracked down and the code is on this else ineffective_prio:
-----------sched.c341-----------------else { sleep_period = (sleep_period * 17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau)); if (!sleep_period) return p->static_prio; }
Quoted 6 lines
--------------------------------------
I don't have the time now to track this further today, but what happens if
sleep_periodis too small and tau is too big?
Could this (17 *sleep_period/ (5 * tau + 2) give 0 and so a division
by 0?
This will give a divide by zero.
I will put together a new patch soon with this correction and appropriate logic.
Con
Quoted 52 lines · Con Kolivas
Quoted 44 lines · Roberto Orenstein
Quoted 20 lines · pat erley
I made a small error when I sent Con a piece of magic I wrote up to help the sleep period.
what it says right now:
/kernel/sched.c around line 325
sleep_period= (sleep_period*17 * sleep_period / ((17 * sleep_period / (5 * tau) + 2) * 5 * tau));----------------------------------------------------------^
it should be:
sleep_period= (sleep_period*17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau));--------------------------------------------------------------^
stupid parenthesis.
Quoted 7 lines
a little background. what this essentially is is a taylor approximation of the function ln(66x+1) normalized. ln(66x+1) happens to do a great job oas a weighting function on the range of 0 to 1, and because the input only happens to range from 0 to 1, only 2 terms were needed to do a 'good enough' job.
Pat
I did your correction and I got a kernel panic(attempting to kill init) on boot. It didn't flushed to disk, so it isn't attached, but it panics at
effective_prio+0xcc/0xe0.
With objdump I could see it traps a division by 0:
cc: f7 fb idiv %ebxI remember cleary %ebx being 0 on the panic report.
And I tracked down and the code is on this else ineffective_prio:
-----------sched.c341-----------------else { sleep_period = (sleep_period * 17 * sleep_period / ((17 * sleep_period / (5 * tau + 2)) * 5 * tau)); if (!sleep_period) return p->static_prio; }Quoted 6 lines
--------------------------------------
I don't have the time now to track this further today, but what happens if
sleep_periodis too small and tau is too big?
Could this (17 *sleep_period/ (5 * tau + 2) give 0 and so a division
by 0?
Quoted 4 lines
This will give a divide by zero.
I will put together a new patch soon with this correction and appropriate logic.
Further inspection of this code shows to me that the current version will do the job adequately. The full function Pat put together is a little more complicated and unfortunately falls over with integer logic. This one is a reasonable enough approximation.
So to summarise, if you still wish to test/use this patch, continue using the patch as posted unmodified called:
patch-O1int-0306290223
Con
Summary:
A patch to reduce audio skipping and X jerking under load.
It's looking seriously like I'm talking to myelf here, but just in case there are lurkers testing this patch, there's a big bug that made it think jiffy wraparound was occurring so interactive tasks weren't receiving the boost they deserved. Here is a patch with the fix in.
How to use if you're still thinking of testing:
Use with Hz 1000, and use the granularity patch I posted as well for smoothing X off.
Con
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;
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 = jiffies; p->security =NULL ; retval = -ENOMEM ;
kernel/sched.c +32 -17
91 lines not on this page · raw message
Quoted 2 lines · Con Kolivas
It's looking seriously like I'm talking to myelf here
Let me know when it is sufficiently cooked and I'll give it a run in -mm.
We obviously have issues in there still, and it is good that you guys are working it.
Greetings,
Quoted 2 lines · Con Kolivas
Summary:
A patch to reduce audio skipping and X jerking under load.
I took it out for a quick spin. It kills thud graveyard dead. That's the good news, now for the bad ;-) With a make -j5 running, kasteroids stutters enough to be pretty annoying. The patched kernel is making booboos wrt cc1's priority often enough to nail kasteroids pretty hard. The mouse pointer also jerks around quite a bit,...
Quoted 8 lines
It's looking seriously like I'm talking to myelf here, but just in case there are lurkers testing this patch, there's a big bug that made it think jiffy wraparound was occurring so interactive tasks weren't receiving the boost they deserved. Here is a patch with the fix in.
How to use if you're still thinking of testing:
Use with Hz 1000, and use the granularity patch I posted as well for smoothing X off.
...but I'm not using that, because I wanted to see the pure effects of this patch.
-Mike
Quoted 11 lines · Mike Galbraith
Greetings,
Quoted 2 lines · Con Kolivas
Summary:
A patch to reduce audio skipping and X jerking under load.I took it out for a quick spin. It kills thud graveyard dead. That's the good news, now for the bad ;-) With a make -j5 running, kasteroids stutters enough to be pretty annoying. The patched kernel is making booboos wrt cc1's priority often enough to nail kasteroids pretty hard. The mouse pointer also jerks around quite a bit,...
Consider it not optimised yet. The workings are still evolving but are now close. It errs on the too-easy to get a bonus in the early ms after an app has started at the moment.
Quoted 6 lines
Quoted 6 lines
It's looking seriously like I'm talking to myelf here, but just in case there are lurkers testing this patch, there's a big bug that made it think jiffy wraparound was occurring so interactive tasks weren't receiving the boost they deserved. Here is a patch with the fix in.
Quoted 7 lines
Quoted 4 lines
How to use if you're still thinking of testing:
Use with Hz 1000, and use the granularity patch I posted as well for smoothing
X off....but I'm not using that, because I wanted to see the pure effects of this patch.
Good point. If it's going to be developed properly it should only include what is likely to be used with it.
Con
Quoted 3 lines · Con Kolivas
Consider it not optimised yet. The workings are still evolving but are now close. It errs on the too-easy to get a bonus in the early ms after an app has started at the moment.
Yeah, that's the way it looks from here too. It's getting it right more often than wrong, that's encouraging.
-Mike
Quoted 1 line · Con Kolivas
A patch to reduce audio skipping and X jerking under load.
Can't make XMMS skip audio with "while true; do a = 2; done" while playing moving windows under an X session.
Quoted 4 lines
It's looking seriously like I'm talking to myelf here, but just in case there are lurkers testing this patch, there's a big bug that made it think jiffy wraparound was occurring so interactive tasks weren't receiving the boost they deserved. Here is a patch with the fix in.
Well, you're not talking to yourself. We're listening and testing:
2.5.73-mm2 + patch-O1int + patch-granularity + patch-1000HZ. With this new version of the patch, the mouse cursor jumpiness has returned again, altough in much less extent than in previous versions: it's more difficult to reproduce, but it's present just when logging onto my KDE session on a Red Hat Linux 9 box. For the rest of the session, it's pretty hard difficult to make the mouse cursor to turn jumpy.
Quoted 3 lines
How to use if you're still thinking of testing:
Use with Hz 1000, and use the granularity patch I posted as well for smoothing X off.
Under heavy load (3 simulatenous consoles doing while true; do a=2; done), X feels smooth, but moving windows aggresively, makes X go jerky for a few seconds and some process do starve a little when repainting.
Anyways, at a first glance, it looks really good :-)
On Monday 30 June 2003 07:35, Con Kolivas wrote:
Hi Con,
Quoted 8 lines
A patch to reduce audio skipping and X jerking under load. It's looking seriously like I'm talking to myelf here, but just in case there are lurkers testing this patch, there's a big bug that made it think jiffy wraparound was occurring so interactive tasks weren't receiving the boost they deserved. Here is a patch with the fix in.
How to use if you're still thinking of testing:
Use with Hz 1000, and use the granularity patch I posted as well for smoothing X off.
using 2.5.73-mm2, 1000HZ, patch-O1int-0306301522, patch-granularity-0306271314
"make -j16 bzImage modules" of a 2.5.73-mm2 tree makes XMMS skip easily, X is not very smooth, mouse jumps, X is sometimes not accepting anything for 5-10 seconds every 1-2 minutes, everything freezes, also XMMS, Kmail freezes, an Xterm needs ~40 seconds to open. If the machine is totally idle, Kmail freezes also for ~5 seconds. Tried running X with 0, -1 and -11 w/o much difference.
I still like Felipe's O(1) patch.
Machine: Celeron 1,3GHz, 512MB RAM, 512MB SWAP, IDE (UDMA100), ext3fs, X4.3, WindowMaker.
Please, can we invite Ingo to this thread? I think it is now _really_ the time to get this fixed up :)
ciao, Marc
Quoted 2 lines · Marc-Christian Petersen
"make -j16 bzImage modules" of a 2.5.73-mm2 tree makes XMMS skip easily
Well it would. Try not to do that. We shouldn't optimise
for things which basically nobody would do.
`make -j2' would be more interesting.
On Monday 30 June 2003 11:47, Andrew Morton wrote:
Hi Andrew,
Quoted 4 lines
Quoted 1 line
"make -j16 bzImage modules" of a 2.5.73-mm2 tree makes XMMS skip easily
Well it would. Try not to do that. We shouldn't optimise
for things which basically nobody would do.
`make -j2' would be more interesting.
Well, it shouldn't *imho*. And it is possible. Currently I am running 2.4.20-wolk4.3 and I do "make -j32 bzImage modules" and I cannot make XMMS skip doesn't matter what I do, it is not possible. Even X is smooth, kmail does not freeze, an Xterm needs ~4 seconds to open.
My tree uses the O(1) from Andrea including the fixes.
Now I've tried your suggestion, "make -j2" with .73-mm2 + the mentioned patches. Three skips during the whole compilation (bzImage modules).
ciao, Marc
Quoted 3 lines · Marc-Christian Petersen
Now I've tried your suggestion, "make -j2" with .73-mm2 + the mentioned
patches. Three skips during the whole compilation (bzImage modules).
And what happens without the scheduler patches?
On Monday 30 June 2003 12:17, Andrew Morton wrote:
Hi Andrew,
Quoted 3 lines
Quoted 2 lines
Now I've tried your suggestion, "make -j2" with .73-mm2 + the mentioned
patches. Three skips during the whole compilation (bzImage modules).And what happens without the scheduler patches?
Not countable XMMS skips (read: too many)
ciao, Marc
Quoted 2 lines · Marc-Christian Petersen
Please, can we invite Ingo to this thread? I think it is now _really_ the time to get this fixed up :)
The giants all seem to be busy... are munchkins stackable? ;-)
Quoted 7 lines
Quoted 3 lines · Marc-Christian Petersen
Please, can we invite Ingo to this thread? I think it is now _really_ the time
to get this fixed up :)The giants all seem to be busy... are munchkins stackable? ;-)
Ok this munchkin has some more to contribute.
Here is the next patch which shows a large improvement. Gone is the unnecessary exponential function (sorry Pat it was fun), and now the patch will start calculating interactivity from the first time an application is activated.
This takes away the X jerkiness evident in the previous patches (yes I do believe you MCP). No granularity patch is needed either.
Please test the bejeesus out of this one; MCP your test case is the most valuable.
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;
On Monday 30 June 2003 15:38, Con Kolivas wrote:
Moin Con,
Quoted 1 line
Ok this munchkin has some more to contribute.
hehe.
Quoted 4 lines
Here is the next patch which shows a large improvement. Gone is the unnecessary exponential function (sorry Pat it was fun), and now the patch will start calculating interactivity from the first time an application is activated.
nice.
Quoted 2 lines
This takes away the X jerkiness evident in the previous patches (yes I do believe you MCP). No granularity patch is needed either.
ok.
Quoted 2 lines
Please test the bejeesus out of this one; MCP your test case is the most valuable.
tyvm :) I'll give it a try in ~30 mins.
ciao, Marc
Quoted 7 lines · Mike Galbraith
Quoted 3 lines · Marc-Christian Petersen
Please, can we invite Ingo to this thread? I think it is now _really_ the time
to get this fixed up :)The giants all seem to be busy... are munchkins stackable? ;-)
Ingo, when you come back from Mars :) ... what has been changed from the very first versions of 2.5.x ? I was able to run unrealistic make -j (among other crap) and still have a liquid desktop back then ...
- Davide