On Wed, Jun 24, 2020 at 05:58:31PM +0530, Madhavan Srinivasan wrote: > > > On 6/24/20 4:26 PM, Gautham R Shenoy wrote: > >Hi Kajol, > > > >On Wed, Jun 24, 2020 at 03:47:54PM +0530, Kajol Jain wrote: > >>Patch here adds a cpumask attr to hv_24x7 pmu along with ABI documentation. > >> > >>command:# cat /sys/devices/hv_24x7/cpumask > >>0 > >Since this sysfs interface is read-only, and the user cannot change > >the CPU which will be making the HCALLs to obtain the 24x7 counts, > >does the user even need to know if currently CPU X is the one which is > >going to make HCALLs to retrive the 24x7 counts ? Does it help in any > >kind of trouble-shooting ? > Primary use to expose the cpumask is for the perf tool. > Which has the capability to parse the driver sysfs folder > and understand the cpumask file. Having cpumask > file will reduce the number of perf commandline > parameters (will avoid "-C" option in the perf tool > command line). I can also notify the user which is > the current cpu used to retrieve the counter data.
Fair enough. Can we include this in the patch description ? > > >It would have made sense if the interface was read-write, since a user > >can set this to a CPU which is not running user applications. This > >would help in minimising jitter on those active CPUs running the user > >applications. > > With cpumask backed by hotplug > notifiers, enabling user write access to it will > complicate the code with more additional check. > CPU will come to play only if the user request for > counter data. If not, then there will be no HCALLs made > using the CPU. Well, I was wondering if you could make the interface writable because I couldn't think of the use of a read-only interface. With the perf-use case you have provided, I guess it makes sense. I am ok with it being a read-only interface. > > Maddy -- Thanks and Regards gautham.