On 10/15/2013 12:26 PM, Peter Zijlstra 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
>
> ?
>
Yes, way better.
Thanks,
- Juri
--
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/
