Messages in this thread | | | Date | Tue, 26 Mar 2019 08:32:36 -0500 | From | Josh Poimboeuf <> | Subject | Re: [PATCH] cpu/hotplug: Create SMT sysfs interface for all arches |
| |
On Sun, Mar 24, 2019 at 09:13:18PM +0100, Thomas Gleixner wrote: > On Fri, 1 Mar 2019, Josh Poimboeuf wrote: > > Make the /sys/devices/system/cpu/smt/* files available on all arches, so > > user space has a consistent way to detect whether SMT is enabled. > > > > The 'control' file now shows 'notsupported' for architectures which > > don't yet have CONFIG_HOTPLUG_SMT. > > I'm slowly crawling through my backlog ... > > > --- a/Documentation/ABI/testing/sysfs-devices-system-cpu > > +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu > > @@ -514,7 +514,8 @@ Description: Control Symetric Multi Threading (SMT) > > "on" SMT is enabled > > "off" SMT is disabled > > "forceoff" SMT is force disabled. Cannot be changed. > > - "notsupported" SMT is not supported by the CPU > > + "notsupported" Runtime SMT toggling is not currently > > + supported for the architecture > > Second thoughts. I'm not really convinced that changing the meaning of > notsupported and in fact overloading it, is the right thing to do. > notsupported means now: > > CPU does not support it - OR - architecture does not support it > > That's not pretty and we are surely not short of state space. There are > several options for handling this: > > 1) Do not expose the state file, just expose the active file > > 2) Expose the state file, but return -ENOTSUPP or some other sensible error > code > > 3) Expose the state file and let show return 'notimplemented' which is > more accurate. That wouldn't even require to expand the state space > enum. It just can be returned unconditionally.
Makes sense. I like #3. I can post another version.
-- Josh
| |