From Con Kolivas <> Subject Re: Regression seen for patch "sched:dont decrease idle sleep avg" Date Thu, 18 May 2006 11:38:25 +1000
`On Thursday 18 May 2006 11:10, Chen, Kenneth W wrote:> Con Kolivas wrote on Wednesday, May 17, 2006 5:35 PM>> > What is missing> > from the comment is to say that it is also designed to stop them at the> > lowest possible priority that still keeps them in the interactive> > reinsertion class.> >> > Using a constant ceiling value irrespective of nice will not guarantee> > that tasks fall into the active reinsertion class dependant on their nice> > value.>> If I may ask, how does it work right now?  Ceiling is set at constant value> irrespective to nice value.  Are you saying current code is broken as well?In essence, yes. The approximation was too general and vague as you have pointed out, and was only close to the correct ceiling or knee for one nice value.  I just want to formalise the relationship between the ceiling, nice value and INTERACTIVE_SLEEP and make the comment clear enough to be understood.>         ceiling = JIFFIES_TO_NS(MAX_SLEEP_AVG ->                   DEF_TIMESLICE);>         if (p->sleep_avg < ceiling)>                   p->sleep_avg = ceiling;>>> We maybe also misunderstand each other.  I'm not arguing of removing the> ceiling. Having a ceiling is the right thing to do here.  What I don't like> is that 2.6.17-rc4 has the ceiling set too high, and your patch also does> an inversion of the ceiling value w.r.t nice value.  So it's the detail of> what's the right value for priority boost that I'm uncomfortable with.We're in fuzzy land where there are no absolutes I'm afraid. The common case is obviously nice 0 and anything else is simply respecting the relationship between nice and INTERACTIVE_SLEEP. As timeslices get proportionately larger the lower the nice value, it becomes increasingly easy to avoid getting to the end of a full timeslice thereby avoiding expiration anyway. It also doesn't take much sleep from a task to get to best priority from the priority knee/ceiling no matter how low it is. Finally the relationship between likely preemption with varying nice levels is sort of vaguely maintained. On balance it seems satisfactory to me to maintain this relationship.-- -ck-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`

Last update: 2006-05-18 03:41    [W:0.059 / U:0.848 seconds]