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

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


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:


Try different values: 1000, 2000, 3000 ... are you able to reproduce it

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:

 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at
Please read the FAQ at

[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