On 13 July 2016 at 18:37, Morten Rasmussen <[email protected]> wrote: > On Wed, Jul 13, 2016 at 02:48:24PM +0100, Dietmar Eggemann wrote: >> On 13/07/16 13:40, Vincent Guittot wrote: >> > On 22 June 2016 at 19:03, Morten Rasmussen <[email protected]> >> > wrote: >> >> From: Dietmar Eggemann <[email protected]> >> >> >> >> To be able to compare the capacity of the target cpu with the highest >> >> available cpu capacity, store the maximum per-cpu capacity in the root >> >> domain. >> > >> > I thought that the capacity of all CPUS were built so the highest >> > capacity of the CPU of the system is 1024 for big LITTLE system . So >> > this patch doesn't seem necessary for big.LITTLE system >> >> The asymmetric cpu capacity support currently only has an effect on arm >> big.LITTLE (32bit) using the existing 'struct cpu_efficiency >> table_efficiency[]' based approach. > > True for this patch set, but longer term and if you use the preview > branch mentioned in the cover letter Vincent is right. The idea is that > the highest capacity anywhere should be 1024. > > If we fix the arch/arm/kernel/topology.c code at the same time we could > kill this patch. > > However, even further down the road we might need it (or something > similar) anyway due to the thermal framework. At some point we would > like to adjust the max capacity based any OPP constraints imposed by the > thermal framework. In extreme cases big cpus might be capped so hard > that they effectively have smaller capacity than little. I don't think > it makes sense to re-normalize everything to the highest available > capacity to ensure that there is always a cpu with capacity = 1024 in > the system, instead we must be able to cope with scenarios where max > capacity is smaller than 1024.
Yes we will have to found a solution for thermal mitigation but i don't know if a rd->max_cpu_capacity would the best solution > > Also, for SMT max capacity is less than 1024 already. No? Yes, it is. I haven't looked in details but i think that we could use a capacity of 1024 for SMT with changes that have been done on how to evaluate if a sched_group is overloaded or not. > But we may be able to cater for this in wake_cap() somehow. I can have a > look if Vincent doesn't like this patch. IMO, rd->max_cpu_capacity field doesn't seem to be required for now . Vincent > > Cheers, > Morten
