linux-kernel - Re: [PATCH v2 06/13] sched: Store maximum per-cpu capacity in root domain

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160713163723.GC21816@e105550-lin.cambridge.arm.com>
Date:	Wed, 13 Jul 2016 17:37:24 +0100
From:	Morten Rasmussen <morten.rasmussen@....com>
To:	Dietmar Eggemann <dietmar.eggemann@....com>
Cc:	Vincent Guittot <vincent.guittot@...aro.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	Yuyang Du <yuyang.du@...el.com>, mgalbraith@...e.de,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [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 <morten.rasmussen@....com> wrote:
> >> From: Dietmar Eggemann <dietmar.eggemann@....com>
> >>
> >> 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.

Cheers,
Morten