On Sat, 2009-09-12 at 13:48 +0200, Martin Steigerwald wrote: > Am Mittwoch 09 September 2009 schrieb Mike Galbraith: > > On Wed, 2009-09-09 at 19:06 +0200, Peter Zijlstra wrote: > > > On Wed, 2009-09-09 at 09:55 -0700, Dmitry Torokhov wrote: > > > > On Wed, Sep 09, 2009 at 03:37:34PM +0000, tip-bot for Mike Galbraith > wrote: > > > > > diff --git a/kernel/kthread.c b/kernel/kthread.c > > > > > index eb8751a..5fe7099 100644 > > > > > --- a/kernel/kthread.c > > > > > +++ b/kernel/kthread.c > > > > > @@ -16,8 +16,6 @@ > > > > > #include <linux/mutex.h> > > > > > #include <trace/events/sched.h> > > > > > > > > > > -#define KTHREAD_NICE_LEVEL (-5) > > > > > - > > > > > > > > Why don't we just redefine it to 0? We may find out later that we'd > > > > still prefer to have kernel threads have boost. > > > > > > Seems sensible, also the traditional reasoning behind this nice level > > > is that kernel threads do work on behalf of multiple tasks. Its a > > > kind of prio ceiling thing. > > > > True. None of our current threads are heavy enough to matter much. > > Does it make sense to have this as a tunable? Where does it matter? Server > workloads? I don't think it should be a knob. It only makes a difference to kthreads that are heavy CPU users. If one pops up as a performance problem, IMHO, it should be tweaked separately. Running at default weight saves a bit of unnecessary math for the common case. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|