Re: [SCHED] wrong priority calc - SIMPLE test case

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <[email protected]> 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 

Attachment: sched_throttle
Description: Binary data


[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux