On Fri, Oct 20, 2023 at 12:53:29PM +0100, Russell King (Oracle) wrote: > On Thu, Sep 14, 2023 at 01:01:26PM +0100, Jonathan Cameron wrote: > > On Wed, 13 Sep 2023 16:37:59 +0000 > > James Morse <james.morse@xxxxxxx> wrote: > > > > > register_cpu_capacity_sysctl() adds a property to sysfs that describes > > > the CPUs capacity. This is done from a subsys_initcall() that assumes > > > all possible CPUs are registered. > > > > > > With CPU hotplug, possible CPUs aren't registered until they become > > > present, (or for arm64 enabled). This leads to messages during boot: > > > | register_cpu_capacity_sysctl: too early to get CPU1 device! > > > and once these CPUs are added to the system, the file is missing. > > > > > > Move this to a cpuhp callback, so that the file is created once > > > CPUs are brought online. This covers CPUs that are added late by > > > mechanisms like hotplug. > > > One observable difference is the file is now missing for offline CPUs. > > > > > > Signed-off-by: James Morse <james.morse@xxxxxxx> > > > --- > > > If the offline CPUs thing is a problem for the tools that consume > > > this value, we'd need to move cpu_capacity to be part of cpu.c's > > > common_cpu_attr_groups. > > > > I think we should do that anyway and then use an is_visible() if we want to > > change whether it is visible in offline cpus. > > > > Dynamic sysfs file creation is horrible - particularly when done > > from an totally different file from where the rest of the attributes > > are registered. I'm curious what the history behind that is. > > > > Whilst here, why is there a common_cpu_attr_groups which is > > identical to the hotpluggable_cpu_attr_groups in base/cpu.c? > > > > > > +CC GregKH > > Given changes in drivers/base/ > > It would be good to have a comment on this from Greg before I post > an updated series of James' patches with most of the comments > addressed, possibly later today. Sorry, I don't see what I am supposed to comment on, so please just send a new series and I'll look at that. thanks, greg k-h
