On Tue, Dec 13, 2022 at 03:31:06PM +0100 Greg Kroah-Hartman wrote: > On Tue, Dec 13, 2022 at 08:22:58AM -0500, Phil Auld wrote: > > On Tue, Dec 13, 2022 at 07:23:54AM +0100 Greg Kroah-Hartman wrote: > > > On Mon, Dec 12, 2022 at 02:17:58PM -0500, Phil Auld wrote: > > > > Hi, > > > > > > > > On Tue, Nov 08, 2022 at 01:24:39PM +0100 Greg Kroah-Hartman wrote: > > > > > On Tue, Nov 08, 2022 at 03:30:46PM +0530, Vishal Chourasia wrote: > > > > > > > > > > > > Thanks Greg & Peter for your direction. > > > > > > > > > > > > While we pursue the idea of having debugfs based on kernfs, we > > > > > > thought about > > > > > > having a boot time parameter which would disable creating and > > > > > > updating of the > > > > > > sched_domain debugfs files and this would also be useful even when > > > > > > the kernfs > > > > > > solution kicks in, as users who may not care about these debugfs > > > > > > files would > > > > > > benefit from a faster CPU hotplug operation. > > > > > > > > > > Ick, no, you would be adding a new user/kernel api that you will be > > > > > required to support for the next 20+ years. Just to get over a > > > > > short-term issue before you solve the problem properly. > > > > > > > > I'm not convinced moving these files from debugfs to kernfs is the right > > > > fix. That will take it from ~50 back to ~20 _minutes_ on these systems. > > > > I don't think either of those numbers is reasonable. > > > > > > > > The issue as I see it is the full rebuild for every change with no way > > > > to > > > > batch the changes. How about something like the below? > > > > > > > > This puts the domains/* files under the sched_verbose flag. About the > > > > only > > > > thing under that flag now are the detailed topology discovery printks > > > > anyway > > > > so this fits together nicely. > > > > > > > > This way the files would be off by default (assuming you don't boot with > > > > sched_verbose) and can be created at runtime by enabling verbose. > > > > Multiple > > > > changes could also be batched by disabling/makeing changes/re-enabling. > > > > > > > > It does not create a new API, uses one that is already there. > > > > > > The idea seems good, the implementation might need a bit of work :) > > > > More than the one comment below? Let me know. > > No idea, resubmit a working patch and I'll review it properly :) >
Will do. Thanks, Phil --
