All of lore.kernel.org
 help / color / mirror / Atom feed
From: Morten Rasmussen <morten.rasmussen@arm.com>
To: Qais Yousef <qais.yousef@arm.com>
Cc: vincent.guittot@linaro.org, peterz@infradead.org,
	linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com,
	mingo@redhat.com, valentin.schneider@arm.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4] sched/topology: SD_ASYM_CPUCAPACITY flag detection
Date: Tue, 24 Jul 2018 09:37:10 +0100	[thread overview]
Message-ID: <20180724083710.GB29978@e105550-lin.cambridge.arm.com> (raw)
In-Reply-To: <b75f665f-7d60-5d83-eaf6-88c534afe254@arm.com>

On Mon, Jul 23, 2018 at 05:07:50PM +0100, Qais Yousef wrote:
> On 23/07/18 16:27, Morten Rasmussen wrote:
> >It does increase the cost of things like hotplug slightly and
> >repartitioning of root_domains a slightly but I don't see how we can
> >avoid it if we want generic code to set this flag. If the costs are not
> >acceptable I think the only option is to make the detection architecture
> >specific.
> 
> I think hotplug is already expensive and this overhead would be small in
> comparison. But this could be called when frequency changes if I understood
> correctly - this is the one I wasn't sure how 'hot' it could be. I wouldn't
> expect frequency changes at a very high rate because it's relatively
> expensive too..

A frequency change shouldn't lead to a flag change or a rebuild of the
sched_domain hierarhcy. The situations where the hierarchy should be
rebuild to update the flag is during boot as we only know the amount of
asymmetry once cpufreq has been initialized, when cpus are hotplugged
in/out, and when root_domains change due to cpuset reconfiguration. So
it should be a relatively rare event.

WARNING: multiple messages have this Message-ID (diff)
From: morten.rasmussen@arm.com (Morten Rasmussen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] sched/topology: SD_ASYM_CPUCAPACITY flag detection
Date: Tue, 24 Jul 2018 09:37:10 +0100	[thread overview]
Message-ID: <20180724083710.GB29978@e105550-lin.cambridge.arm.com> (raw)
In-Reply-To: <b75f665f-7d60-5d83-eaf6-88c534afe254@arm.com>

On Mon, Jul 23, 2018 at 05:07:50PM +0100, Qais Yousef wrote:
> On 23/07/18 16:27, Morten Rasmussen wrote:
> >It does increase the cost of things like hotplug slightly and
> >repartitioning of root_domains a slightly but I don't see how we can
> >avoid it if we want generic code to set this flag. If the costs are not
> >acceptable I think the only option is to make the detection architecture
> >specific.
> 
> I think hotplug is already expensive and this overhead would be small in
> comparison. But this could be called when frequency changes if I understood
> correctly - this is the one I wasn't sure how 'hot' it could be. I wouldn't
> expect frequency changes at a very high rate because it's relatively
> expensive too..

A frequency change shouldn't lead to a flag change or a rebuild of the
sched_domain hierarhcy. The situations where the hierarchy should be
rebuild to update the flag is during boot as we only know the amount of
asymmetry once cpufreq has been initialized, when cpus are hotplugged
in/out, and when root_domains change due to cpuset reconfiguration. So
it should be a relatively rare event.

  reply	other threads:[~2018-07-24  8:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-20 13:32 [PATCH 0/4] sched/topology: Set SD_ASYM_CPUCAPACITY flag automatically Morten Rasmussen
2018-07-20 13:32 ` Morten Rasmussen
2018-07-20 13:32 ` [PATCH 1/4] sched/topology: SD_ASYM_CPUCAPACITY flag detection Morten Rasmussen
2018-07-20 13:32   ` Morten Rasmussen
2018-07-23 13:25   ` Qais Yousef
2018-07-23 13:25     ` Qais Yousef
2018-07-23 15:27     ` Morten Rasmussen
2018-07-23 15:27       ` Morten Rasmussen
2018-07-23 16:07       ` Qais Yousef
2018-07-23 16:07         ` Qais Yousef
2018-07-24  8:37         ` Morten Rasmussen [this message]
2018-07-24  8:37           ` Morten Rasmussen
2018-07-24  8:59           ` Qais Yousef
2018-07-24  8:59             ` Qais Yousef
2018-09-10  8:21   ` Ingo Molnar
2018-09-10  8:21     ` Ingo Molnar
2018-09-11 11:04     ` Morten Rasmussen
2018-09-11 11:04       ` Morten Rasmussen
2018-09-10 10:11   ` [tip:sched/core] sched/topology: Add " tip-bot for Morten Rasmussen
2018-07-20 13:32 ` [PATCH 2/4] drivers/base/arch_topology: Rebuild sched_domain hierarchy when capacities change Morten Rasmussen
2018-07-20 13:32   ` Morten Rasmussen
2018-09-10 10:11   ` [tip:sched/core] sched/topology, drivers/base/arch_topology: Rebuild the " tip-bot for Morten Rasmussen
2018-07-20 13:32 ` [PATCH 3/4] arch/arm64: Rebuild sched_domain hierarchy when cpu capacity changes Morten Rasmussen
2018-07-20 13:32   ` Morten Rasmussen
2018-09-10 10:12   ` [tip:sched/core] sched/topology, arch/arm64: Rebuild the sched_domain hierarchy when the CPU " tip-bot for Morten Rasmussen
2018-07-20 13:32 ` [PATCH 4/4] arch/arm: Rebuild sched_domain hierarchy when cpu " Morten Rasmussen
2018-07-20 13:32   ` Morten Rasmussen
2018-09-10 10:12   ` [tip:sched/core] sched/topology, arch/arm: Rebuild sched_domain hierarchy when CPU " tip-bot for Morten Rasmussen
2018-07-31 10:53 ` [PATCH 0/4] sched/topology: Set SD_ASYM_CPUCAPACITY flag automatically Peter Zijlstra
2018-07-31 10:53   ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180724083710.GB29978@e105550-lin.cambridge.arm.com \
    --to=morten.rasmussen@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.