Messages in this thread | | | Date | Mon, 09 Jan 2006 12:11:31 +0100 | From | Mike Galbraith <> | Subject | Re: [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] | |