Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1654449 > unrolled thread

Re: [PATCH] ARM: cpuidle: Support asymmetric idle definition

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] ARM: cpuidle: Support asymmetric idle definition Daniel Lezcano <daniel.lezcano@linaro.org> - 2017-05-31 18:50 +0200
    Re: [PATCH] ARM: cpuidle: Support asymmetric idle definition Sudeep Holla <sudeep.holla@arm.com> - 2017-05-31 19:40 +0200
      Re: [PATCH] ARM: cpuidle: Support asymmetric idle definition Daniel Lezcano <daniel.lezcano@linaro.org> - 2017-06-01 09:40 +0200

#1654449 — Re: [PATCH] ARM: cpuidle: Support asymmetric idle definition

On 22/05/2017 17:02, Sudeep Holla wrote:
> 
> 
> On 22/05/17 15:48, Daniel Lezcano wrote:
>> On 22/05/2017 15:02, Sudeep Holla wrote:
>>
>> [ ... ]
>>
>>>>>>>> +		drv->cpumask = &cpu_topology[cpu].core_sibling;
>>>>>>>> +
>>>>>>>
>>>>>>> This is not always true and not architecturally guaranteed. So instead
>>>>>>> of introducing this broken dependency, better to extract information
>>>>>>> from the device tree.
>>>>>>
>>>>>> Can you give an example of a broken dependency ?
>>>>>>
>>>>>> The cpu topology information is extracted from the device tree. So
>>>>>> if the topology is broken, the DT is broken also. Otherwise, the
>>>>>> topology code must fix the broken dependency from the DT.
>>>>>>
>>>>>
>>>>> No, I meant there's no guarantee that all designs must follow this rule.
>>>>> I don't mean CPU topology code or binding is broken. What I meant is
>>>>> linking CPU topology to CPU power domains is wrong. We should make use
>>>>> of DT you infer this information as it's already there. Topology bindings
>>>>> makes no reference to power and hence you simply can't infer that
>>>>> information from it.
>>>>
>>>> Ok, I will have a look how power domains can fit in this.
>>>>
>>>> However I'm curious to know a platform with a cluster idle state
>>>> powering down only a subset of CPUs belonging to the cluster.
>>>>
>>>
>>> We can't reuse CPU topology for power domains:
>>> 1. As I mentioned earlier for sure, it won't be same with ARM DynamIQ.
>>> 2. Topology bindings strictly restrict themselves with topology and not
>>> connected with power-domains. We also have separate power domain
>>> bindings.
>>
>> Yes, the theory is valid, but practically nowadays I don't see where we
>> have a cluster defined by a topology with a different cluster power domain.
>>
> 
> While I agree that it's true in current practice, but in past we have
> seen "innovative designs". We initially had 2 clusters(big and little)
> then we saw 3 cluster(big little and tiny or whatever you what to call)
> So as it's not architecturally guaranteed, it's not nice to make this
> assumption in a generic driver.
> 
>> By the way, if you have any pointer to documentation for DynamIQ PM and
>> design? I would be interested to have a look.
>>
> 
> I don't have anything in detail. Excerpts from the link I sent earlier
> indicate that it's possible and highly likely.
> 
> "DynamIQ supports multiple, configurable, performance domains within a
> single cluster. These domains, consisting of single or multiple ARM
> CPUs, can scale in performance and power with finer granularity than
> previous quad-core clusters."
> 
>>> We need to separate topology and power domains. We have some dependency
>>> like this in big little drivers(both CPUfreq and CPUIdle) but that
>>> dependencies must be removed as they are not architecturally guaranteed.
>>> Lorenzo had a patch[1] to solve this issue, I can post the latest
>>> version of it again and continue the discussion after some basic
>>> rebase/testing.
>>
>> Actually, I am not convinced by the approach proposed in this patch.
>>
>> Let me have a look at the idle power domain before, I do believe we can
>> do something much more simple.
>>
> 
> OK, if you think so.

Hi Sudeep, Lorenzo,

I have been thinking and looking at the domain-idle-state and I don't
see an obvious connection between what is describing the power domain,
the cpu idle driver and what we are trying to achieve.

I would like to suggest something much more simple, register a cpuidle
driver per cpu, so every cpu can have its own idle definitions, that
should work for dynamiQ, smp and hmp. The impact on the driver will be
minimal.



-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[toc] | [next] | [standalone]

#1654489

On 31/05/17 17:40, Daniel Lezcano wrote:

> Hi Sudeep, Lorenzo,
> 
> I have been thinking and looking at the domain-idle-state and I don't
> see an obvious connection between what is describing the power domain,
> the cpu idle driver and what we are trying to achieve.
>

I am not sure what you mean by *connection* above.

1. With old flat list of idle states, we should get the cpumask sharing
   the idle states from the phandle or something similar.
2. With new domain-idle-state and hierarchical DT binding, you just need
   to infer that from the hierarchy.

> I would like to suggest something much more simple, register a cpuidle
> driver per cpu, so every cpu can have its own idle definitions, that
> should work for dynamiQ, smp and hmp. The impact on the driver will be
> minimal.
> 

Sounds simple, but not sure if it's scalable on platforms with
relatively large number of CPUs like 48 or 96(e.g. Cavium Thunder
-- 
Regards,
Sudeep

[toc] | [prev] | [next] | [standalone]

#1654888

On 31/05/2017 19:33, Sudeep Holla wrote:
> 
> 
> On 31/05/17 17:40, Daniel Lezcano wrote:
> 
>> Hi Sudeep, Lorenzo,
>>
>> I have been thinking and looking at the domain-idle-state and I don't
>> see an obvious connection between what is describing the power domain,
>> the cpu idle driver and what we are trying to achieve.
>>
> 
> I am not sure what you mean by *connection* above.
> 
> 1. With old flat list of idle states, we should get the cpumask sharing
>    the idle states from the phandle or something similar.
> 2. With new domain-idle-state and hierarchical DT binding, you just need
>    to infer that from the hierarchy.
> 
>> I would like to suggest something much more simple, register a cpuidle
>> driver per cpu, so every cpu can have its own idle definitions, that
>> should work for dynamiQ, smp and hmp. The impact on the driver will be
>> minimal.
>>
> 
> Sounds simple, but not sure if it's scalable on platforms with
> relatively large number of CPUs like 48 or 96(e.g. Cavium Thunder

I'm pretty sure it scales, we had the idle states per cpuidle devices
and nobody was complaining. But I agree it could be optimized.


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web