2013/4/25 Ingo Molnar <[email protected]>:
>
> * Frederic Weisbecker <[email protected]> wrote:
>
>> > depends on VIRT_CPU_ACCOUNTING_GEN
>> >
>> > It should _really_ select both the RCU and the CPU time accounting model
>> > automatically!
>>
>> Yeah I know. I have yet to fix that in Kconfig (it's a Kconfig limitation).
>
> Why cannot we simply select it and its dependencies, explicitly, for the
> time being? Something like:
>
> depends on 64BIT
> select VIRT_CPU_ACCOUNTING
> select VIRT_CPU_ACCOUNTING_GEN
>
> 90% of the .config's have VIRT_CPU_ACCOUNTING_GEN turned off, because it's
> a default-off feature - so dynticks-full is effectively hidden from the
> large majority of testers...
Whatever we do, it seems that select does not work with choices.
Michal, we are running into an issue where a Kconfig option needs to
select CONFIG_VIRT_CPU_ACCOUNTING_GEN but this latter option is part
of a choice menu so it doesn't work. As a result we are forced to use
a "depends on" and this hides the high level option we are interested
in (here full dynticks) behind its low level dependency. How hard do
you think it would be to fix this? I tried something that worked
half-way but I quickly got lost in the Kconfig maze.
Thanks.
* Frederic Weisbecker <[email protected]> wrote:
> 2013/4/25 Ingo Molnar <[email protected]>:
> >
> > * Frederic Weisbecker <[email protected]> wrote:
> >
> >> > depends on VIRT_CPU_ACCOUNTING_GEN
> >> >
> >> > It should _really_ select both the RCU and the CPU time accounting model
> >> > automatically!
> >>
> >> Yeah I know. I have yet to fix that in Kconfig (it's a Kconfig limitation).
> >
> > Why cannot we simply select it and its dependencies, explicitly, for the
> > time being? Something like:
> >
> > depends on 64BIT
> > select VIRT_CPU_ACCOUNTING
> > select VIRT_CPU_ACCOUNTING_GEN
> >
> > 90% of the .config's have VIRT_CPU_ACCOUNTING_GEN turned off, because it's
> > a default-off feature - so dynticks-full is effectively hidden from the
> > large majority of testers...
>
> Whatever we do, it seems that select does not work with choices.
>
> Michal, we are running into an issue where a Kconfig option needs to
> select CONFIG_VIRT_CPU_ACCOUNTING_GEN but this latter option is part of
> a choice menu so it doesn't work. As a result we are forced to use a
> "depends on" and this hides the high level option we are interested in
> (here full dynticks) behind its low level dependency. How hard do you
> think it would be to fix this? I tried something that worked half-way
> but I quickly got lost in the Kconfig maze.
While it's not an ideal solution, we could try to create three bools out
of the choice options, as a workaround?
Thanks,
Ingo
2013/4/25 Ingo Molnar <[email protected]>:
>
> * Frederic Weisbecker <[email protected]> wrote:
>
>> 2013/4/25 Ingo Molnar <[email protected]>:
>> >
>> > * Frederic Weisbecker <[email protected]> wrote:
>> >
>> >> > depends on VIRT_CPU_ACCOUNTING_GEN
>> >> >
>> >> > It should _really_ select both the RCU and the CPU time accounting model
>> >> > automatically!
>> >>
>> >> Yeah I know. I have yet to fix that in Kconfig (it's a Kconfig limitation).
>> >
>> > Why cannot we simply select it and its dependencies, explicitly, for the
>> > time being? Something like:
>> >
>> > depends on 64BIT
>> > select VIRT_CPU_ACCOUNTING
>> > select VIRT_CPU_ACCOUNTING_GEN
>> >
>> > 90% of the .config's have VIRT_CPU_ACCOUNTING_GEN turned off, because it's
>> > a default-off feature - so dynticks-full is effectively hidden from the
>> > large majority of testers...
>>
>> Whatever we do, it seems that select does not work with choices.
>>
>> Michal, we are running into an issue where a Kconfig option needs to
>> select CONFIG_VIRT_CPU_ACCOUNTING_GEN but this latter option is part of
>> a choice menu so it doesn't work. As a result we are forced to use a
>> "depends on" and this hides the high level option we are interested in
>> (here full dynticks) behind its low level dependency. How hard do you
>> think it would be to fix this? I tried something that worked half-way
>> but I quickly got lost in the Kconfig maze.
>
> While it's not an ideal solution, we could try to create three bools out
> of the choice options, as a workaround?
I thought about that yeah, at least for a temporary solution. Let's
try it, I'll see what I can get.
2013/4/25 Frederic Weisbecker <[email protected]>:
> 2013/4/25 Ingo Molnar <[email protected]>:
>>
>> * Frederic Weisbecker <[email protected]> wrote:
>>
>>> 2013/4/25 Ingo Molnar <[email protected]>:
>>> >
>>> > * Frederic Weisbecker <[email protected]> wrote:
>>> >
>>> >> > depends on VIRT_CPU_ACCOUNTING_GEN
>>> >> >
>>> >> > It should _really_ select both the RCU and the CPU time accounting model
>>> >> > automatically!
>>> >>
>>> >> Yeah I know. I have yet to fix that in Kconfig (it's a Kconfig limitation).
>>> >
>>> > Why cannot we simply select it and its dependencies, explicitly, for the
>>> > time being? Something like:
>>> >
>>> > depends on 64BIT
>>> > select VIRT_CPU_ACCOUNTING
>>> > select VIRT_CPU_ACCOUNTING_GEN
>>> >
>>> > 90% of the .config's have VIRT_CPU_ACCOUNTING_GEN turned off, because it's
>>> > a default-off feature - so dynticks-full is effectively hidden from the
>>> > large majority of testers...
>>>
>>> Whatever we do, it seems that select does not work with choices.
>>>
>>> Michal, we are running into an issue where a Kconfig option needs to
>>> select CONFIG_VIRT_CPU_ACCOUNTING_GEN but this latter option is part of
>>> a choice menu so it doesn't work. As a result we are forced to use a
>>> "depends on" and this hides the high level option we are interested in
>>> (here full dynticks) behind its low level dependency. How hard do you
>>> think it would be to fix this? I tried something that worked half-way
>>> but I quickly got lost in the Kconfig maze.
>>
>> While it's not an ideal solution, we could try to create three bools out
>> of the choice options, as a workaround?
>
> I thought about that yeah, at least for a temporary solution. Let's
> try it, I'll see what I can get.
Oh wait, looking at how rcu manages its flavour choices against SMP
and PREEMPT, I think I can inspire from it. I have the patch ready,
just making some tests to be sure.