[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190307151954.GB5778@e107155-lin>
Date: Thu, 7 Mar 2019 15:19:54 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Lingutla Chandrasekhar <clingutla@...eaurora.org>
Cc: quentin.perret@....com, dietmar.eggemann@....com,
gregkh@...uxfoundation.org, will.deacon@....com,
catalin.marinas@....com, morten.rasmussen@....com,
linux-arm-kernel@...ts.infradead.org, jeremy.linton@....com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] arch_topology: Make cpu_capacity sysfs node as
ready-only
On Wed, Mar 06, 2019 at 08:57:53PM +0530, Lingutla Chandrasekhar wrote:
> If user updates any cpu's cpu_capacity, then the new value is going to
> be applied to all its online sibling cpus. But this need not to be correct
> always, as sibling cpus (in ARM, same micro architecture cpus) would have
> different cpu_capacity with different performance characteristics.
> So updating the user supplied cpu_capacity to all cpu siblings
> is not correct.
>
> And another problem is, current code assumes that 'all cpus in a cluster
> or with same package_id (core_siblings), would have same cpu_capacity'.
> But with commit '5bdd2b3f0f8 ("arm64: topology: add support to remove
> cpu topology sibling masks")', when a cpu hotplugged out, the cpu
> information gets cleared in its sibling cpus. So user supplied
> cpu_capacity would be applied to only online sibling cpus at the time.
> After that, if any cpu hot plugged in, it would have different cpu_capacity
> than its siblings, which breaks the above assumption.
>
> So instead of mucking around the core sibling mask for user supplied
> value, use device-tree to set cpu capacity. And make the cpu_capacity
> node as read-only to know the assymetry between cpus in the system.
>
Acked-by: Sudeep Holla <sudeep.holla@....com>
IIRC this was added for 2 possibilities though I don't completely agree
no one had any objections(including me though I wonder how/why I missed
to notice it now, anyways it's too late)
1. For systems that don't provide this information via device-tree/any
firmware though that's the highly recommended way. With more complex
topologies in horizon, I can't think of fetching/deducing this
information *correctly* in any other sane way.
2. For some sort of tuning(avoid rebuild and reboot), but that's
questionable as this is not a software characteristic. It's more
like deriving hardware characteristics using software experiments.
So, for me, we can compare this with some hardware latencies we have
like CPU idle entry/exit latencies. They are tuned but not in
production kernels. So if there's a case for adding this back as
write capable sysfs, I would prefer that in debugfs and this sysfs
is read-only ABI.
Hope that helps.
--
Regards,
Sudeep
Powered by blists - more mailing lists