Re: [PATCH 12/14] sched: make dl_bw a sub-quota of rt_bw

[Ingo Molnar]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Tue, Oct 15, 2013 at 12:00:20PM +0200, Juri Lelli wrote:
> > On 10/14/2013 04:06 PM, Ingo Molnar wrote:
> > > 
> > > * Juri Lelli <juri.lelli@xxxxxxxxx> wrote:
> > > 
> > >> +#ifdef CONFIG_SMP
> > >> +		struct dl_bw *dl_b = &cpu_rq(i)->rd->dl_bw;
> > >> +#else
> > >> +		struct dl_bw *dl_b = &cpu_rq(i)->dl.dl_bw;
> > >> +#endif
> > > 
> > >> +#ifdef CONFIG_SMP
> > >> +		struct dl_bw *dl_b = &cpu_rq(i)->rd->dl_bw;
> > >> +#else
> > >> +		struct dl_bw *dl_b = &cpu_rq(i)->dl.dl_bw;
> > >> +#endif
> > > 
> > > Btw., this kind of SMP/UP assymetry pattern really sucks. Why not make UP 
> > > use the SMP data structure, even if it's degenerate?
> > > 
> > 
> > Yes, I don't like it either, but that comes from the fact that it seemed to me
> > that, semantically, bandwidth for -deadline tasks has to be associated to the
> > single runqueue in UP and to the root_domain for SMP. In UP root_domain is
> > compiled out, so I'm not sure to understand what you suggest. I could probably
> > let dl_bw live on runqueues with the assumption that all the runqueues from the
> > same root_domain have the same dl_bw, that represents the dl_bw of the
> > root_domain. But I don't like this replication either :(.
> 
> #ifdef CONFIG_SMP
> 
> static inline struct dl_bw *dl_bw_of(int i)
> {
> 	return &cpu_rq(i)->rd->dl_bw;
> }
> 
> #else
> 
> static inline struct dl_bw *dl_bw_of(int i)
> {
> 	return &cpu_rq(i)->dl.dl_bw;
> }
> 
> #endif
> 
> ?

Really, please make it _symmetric_ ...

Single core systems are becoming a historic curiosity, should we should 
justify every piece of extra complexity we add for them.

So I'd rather see obvious SMP code where the UP case works fine too, and 
_then_ maybe check a separate patch that adds the UP optimization, with 
(object size) numbers proving that it's worth it, etc.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/