[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1269376324.5283.6.camel@laptop>
Date: Tue, 23 Mar 2010 21:32:04 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Fabio Checconi <fchecconi@...il.com>
Cc: Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
Paul Turner <pjt@...gle.com>,
Dario Faggioli <faggioli@...dalf.sssup.it>,
Michael Trimarchi <michael@...dence.eu.com>,
Dhaval Giani <dhaval@...is.sssup.it>,
Tommaso Cucinotta <t.cucinotta@...up.it>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] sched: enforce per-cpu utilization limits on
runtime balancing
On Wed, 2010-03-03 at 18:00 +0100, Fabio Checconi wrote:
> > From: Peter Zijlstra <peterz@...radead.org>
> > Date: Thu, Feb 25, 2010 09:28:23PM +0100
> >
> > On Tue, 2010-02-23 at 19:56 +0100, Fabio Checconi wrote:
> > > +#ifdef CONFIG_SMP
> > > +static inline unsigned long rt_init_free_bw(void)
> > > +{
> > > + unsigned long used = to_ratio(global_rt_period(), global_rt_runtime());
> > > +
> > > + return to_ratio(RUNTIME_INF, RUNTIME_INF) - used;
> > > +}
> > > +#endif
> >
> > > +static void __rt_restart_balancing(void)
> > > +{
> > > + unsigned long used, global, free;
> > > + struct rq *rq;
> > > + int i;
> > > +
> > > + used = rt_used_bandwidth();
> > > + global = to_ratio(RUNTIME_INF, RUNTIME_INF);
> > > +
> > > + free = global - used;
> >
> >
> > We take the max as RUNTIME_INF instead of global_rt_* so that we can
> > move runtime around and fully saturate a single cpu (given there is
> > enough free to compensate on other cpus) ?
>
> The only reason I've used RUNTIME_INF instead of global_rt_* is for the
> !GROUP_SCHED case, where using the global_rt_* values would make balancing
> have no effect at all (the initial value for def_rt_bandwidth already
> uses the maximum bw on each cpu) . The current throttling implementation
> in this case still tries to concentrate bw on a single cpu, and I wanted
> to replicate the same behaviour.
>
> Should I go for the global_rt_* values and add some #ifdef unreadability
> to avoid the balancing overhead in the !GROUP_SCHED case?
Nah, but adding a comment to clarify this might help.. I only asked
because it was not immediately obvious.
--
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