* Peter Zijlstra <pet...@infradead.org> 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.le...@gmail.com> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
