lkml.org 
[lkml]   [2006]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [SCHED] wrong priority calc - SIMPLE test case
At 10:15 AM 1/2/2006 +0100, Mike Galbraith wrote:
>At 12:39 PM 1/1/2006 +0100, Paolo Ornati wrote:
>>On Sat, 31 Dec 2005 17:37:11 +0100
>>Mike Galbraith <efault@gmx.de> wrote:
>>
>> > Strange. Using the exact same arguments, I do see some odd bouncing up to
>> > high priorities, but they spend the vast majority of their time down
>> at 25.
>>
>>Mmmm... to make it more easly reproducible I've enlarged the sleep time
>>(1 microsecond is likely to be rounded too much and give different
>>results on different hardware/kernel/config...).
>>
>>Compile this _without_ optimizations and try again:
>
><snip>
>
>>Try different values: 1000, 2000, 3000 ... are you able to reproduce it
>>now?
>
>Yeah. One instance running has to sustain roughly _95%_ cpu before it's
>classified as a cpu piggy. Not good.
>
>>If yes, try to start 2 of them with something like this:
>>
>>"./a.out 3000 & ./a.out 3161"
>>
>>so they are NOT syncronized and they use almost all the CPU time:
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 5582 paolo 16 0 2396 320 252 S 45.7 0.1 0:05.52 a.out
>> 5583 paolo 15 0 2392 320 252 S 45.7 0.1 0:05.49 a.out
>>
>>This is the bad situation I hate: some cpu-eaters that eat all the CPU
>>time BUT have a really good priority only because they sleeps a bit.
>
>Yup, your proggy fools the interactivity estimator quite well. This
>problem was addressed a long time ago, and thought to be more or less
>cured. Guess not.

Care to try an experiment? I'd be very interested in knowing if the
attached patch cures the real-life problem you were investigating.

It attempts to catch tasks which the interactivity logic has misidentified,
and "pull their plug". It maintains a running plausibility check
(slice_avg) against sleep_avg, and if a sustained disparity appears, cuts
off a cpu burning task's supply of bonus points such that it has to "run on
battery" until the disparity decreases to within acceptable limits.

Obviously, anything that affects fairness _will_ affect interactivity to
some degree. This simple bolt-on throttle has delayed initiation and
accelerated release in the hopes of keeping it's impact acceptable. After
some initial testing, It doesn't _seem_ to suck.

-Mike [unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2006-01-09 12:14    [W:0.820 / U:1.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site