On Mon, Oct 29, 2018 at 05:35:15PM -0400, Waiman Long wrote: > On 10/29/2018 05:23 PM, Vito Caputo wrote: > > On Mon, Oct 29, 2018 at 04:59:03PM -0400, Waiman Long wrote: > >> On 10/29/2018 04:38 PM, Davidlohr Bueso wrote: > >>> On Mon, 29 Oct 2018, Waiman Long wrote: > >>> > >>>> BTW, since you are making stat2 compatible with stat, will that be > >>>> easier from the user API perspective if we use a sysctl parameter to > >>>> turn on and off IRQs reporting for /proc/stat, for example? > >>> For one /proc/stat is also common for debugging envs (ie: performance) > >>> and I fear that if a tunnable modifies the behavior of the output, we > >>> it might never be usable again (at least not without having users also > >>> now consider the systctl parameter). Making it dynamic I think is not > >>> worth it. > >>> > >>> Thanks, > >>> Davidlohr > >> This is just a matter if it is easier for users to modify their code to > >> use /proc/stat2 or turning on a sysctl parameter. Again, this will > >> certainly depend on the circumstances. > >> > > I wonder if it makes sense to introduce a more general mechanism for > > toggling subfields in proc files. Extended attributes could probably be > > abused to key the subfields, write a 1 or 0 to well-known names for > > toggling them on a per-fd basis via fsetxattr. > > > > For this particular case the program would just have to add code like: > > > > int zero = 0; > > fsetxattr(proc_stat_fd, "intr", &zero, sizeof(zero), XATTR_REPLACE); > > > > Just putting it out there. I've certainly wanted an ability to noop > > fields before where I was polling proc frequently and skipping the bulk > > of what was there but syscpu was still rather high. > > > > I'm definitely not in favor of just adding another stat file that is the > > same format as the existing one with the intrs zeroed out. It's a dirty > > hack; fine for your local needs but too gross for upstream IMHO. > > > > Regards, > > Vito Caputo > > Does procfs allow extended attributes? I am not sure if using extended > attributes is a usual practice for doing this kind of control on a > procfs file. > I'm not aware of any such usage, but I didn't dig into the code to see if there were already conflicting xattr users. If this did turn out to be a reasonable approach, it would probably be wise to prefix the key strings with a namespace in case future uses come up. Like "filter:intr" or something along those lines. WRT procfs support for xattr, if it's not already implemented it's not difficult to add. The important factor is this utilizes an existing vfs api, there's nothing about procfs prohibiting xattr handling. Regards, Vito Caputo
