[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091203091206.GA1478@ucw.cz>
Date: Thu, 3 Dec 2009 10:12:06 +0100
From: Pavel Machek <pavel@....cz>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Christian Ehrhardt <ehrhardt@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...e.hu>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Holger.Wolf@...ibm.com, epasch@...ibm.com,
Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: Missing recalculation of scheduler tunables in case of cpu hot
add/remove
Hi!
> > >>> Aside from that, we probably should put an upper limit in place, as I
> > >>> guess large cpu count machines get silly large values
> > >>>
> > >> I agree to that, but in the code is already an upper limit of
> > >> 200.000.000 - well we might discuss if that is too low/high.
> > >>
> > >
> > > Yeah, I think we should cap it around the 8-16 CPUs.
> > >
> > >
> > ok for me, driven by that finding I think I have to measure different
> > kind of scalings anyway, but as usually that takes some time :-/
> > At least too time much for the discussion & solution of that bug I guess.
> >
> > The question for now is what we do on cpu hot add/remove?
> > Would hooking somewhere in kernel/cpu.c be the right approach - I'm not
> > quite sure about my own suggestion yet :-).
>
> Something like the below might work I suppose, just needs a cleanup and
> such.
I see a rather fundamental problem: what if user wants to override
those values, and wants them stay that way?
If you do this, suspend/resume will put the old values back AFAICT.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists