[lkml]   [2016]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 06/13] sched: Store maximum per-cpu capacity in root domain
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 <> wrote:
> >> From: Dietmar Eggemann <>
> >>
> >> 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.

Also, for SMT max capacity is less than 1024 already. No?
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.


 \ /
  Last update: 2016-07-13 19:21    [W:0.112 / U:1.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site