Messages in this thread | | | Subject | Re: Regression seen for patch "sched:dont decrease idle sleep avg" | From | Mike Galbraith <> | Date | Wed, 17 May 2006 07:24:41 +0200 |
| |
On Wed, 2006-05-17 at 14:45 +1000, Peter Williams wrote: > Mike Galbraith wrote: > > On Tue, 2006-05-16 at 16:32 -0700, Tim Chen wrote: > >> On Tue, 2006-05-16 at 09:45 +1000, Con Kolivas wrote: > >> > >>> Yes it's only designed to detect something that has been asleep for an > >>> arbitrary long time and "categorised as idle"; it is not supposed to be a > >>> priority stepping stone for everything, in this case at MAX_BONUS-1. Mike > >>> proposed doing this instead, but it was never my intent. > >> It seems like just one sleep longer than INTERACTIVE_SLEEP is needed > >> kick the priority of a process all the way to MAX_BONUS-1 and boost the > >> sleep_avg, regardless of what the prior sleep_avg was. > >> > >> So if there is a cpu hog that has long sleeps occasionally, once it woke > >> up, its priority will get boosted close to maximum, likely starving out > >> other processes for a while till its sleep_avg gets reduced. This > >> behavior seems like something to avoid according to the original code > >> comment. Are we boosting the priority too quickly? > > > > The answer to that is, sometimes yes, and when it bites, it bites hard. > > Happily, most hogs don't sleep much, and we don't generally have lots of > > bursty sleepers. > > > > But it's easy for a malicious user to exploit. Yes?
Without limits, sure. Burn malicious idiot's library card :) The real pain begins when you start examining legitimate loads. It _can_ get really and truly fugly. Generally doesn't.
-Mike
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |