[RFC] use of /sys versus /proc

[RFC] use of /sys versus /proc

[Cliff Wickman]

I have a need to display TLB shootdown statistics.  (I'm working
on a patch to implement this on a new machine at SGI.)

I had planned to display these statistics through /proc
as in arch/ia64/sn/kernel/sn2/sn2_smp.c (/proc/sgi_sn/ptc_statistics).

However, considering the general move to reserve /proc for
process-related things, I thought the community might prefer the
interface to be in /sys.

But sysfs has an output buffer restriction of one page, which
is too restrictive for statistics from very large cpu counts.
We intend to display about 10 numbers per cpu.

Besides, the spirit of /sys according to the sysfs.txt documentation:
    "Attributes should be ... preferably with only one value
     per file. ... acceptable to express an array of values of the same type."
  [it also  warns:
    "... expressing multiple lines of data, ... is heavily frowned upon.
     Doing these things may get you publically humiliated and your code
     rewritten without notice."]

If I break up the statistics files per-cpu, or maybe ranges of
cpu's, it would create a potentially large number of files in /sys.

Or, I could stick with a single file in /proc.

What would you recommend?

Thanks.
-Cliff Wickman

Re: [RFC] use of /sys versus /proc

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 496 bytes --]

On Fri, 23 May 2008 08:12:55 CDT, Cliff Wickman said:
> 
> I have a need to display TLB shootdown statistics.  (I'm working
> on a patch to implement this on a new machine at SGI.)
> 
> I had planned to display these statistics through /proc
> as in arch/ia64/sn/kernel/sn2/sn2_smp.c (/proc/sgi_sn/ptc_statistics).
> 
> However, considering the general move to reserve /proc for
> process-related things, I thought the community might prefer the
> interface to be in /sys.

Is debugfs an option?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [RFC] use of /sys versus /proc

[Cliff Wickman]

On Fri, May 23, 2008 at 01:19:20PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 23 May 2008 08:12:55 CDT, Cliff Wickman said:
> > 
> > I have a need to display TLB shootdown statistics.  (I'm working
> > on a patch to implement this on a new machine at SGI.)
> > 
> > I had planned to display these statistics through /proc
> > as in arch/ia64/sn/kernel/sn2/sn2_smp.c (/proc/sgi_sn/ptc_statistics).
> > 
> > However, considering the general move to reserve /proc for
> > process-related things, I thought the community might prefer the
> > interface to be in /sys.
> 
> Is debugfs an option?

I tried that out and it works about like /proc, which is good.
It doesn't clutter /proc.
Plus it can disappear gracefully from the kernel if CONFIG_DEBUG_FS
is set off.  (it is set on in the default x86_64 configuration)

So thanks for the suggestion.  It may be the answer.

-- 
Cliff Wickman
Silicon Graphics, Inc.
cpw@sgi.com
(651) 683-3824

Re: [RFC] use of /sys versus /proc

[Alexey Dobriyan]

On Fri, May 23, 2008 at 08:12:55AM -0500, Cliff Wickman wrote:
> I have a need to display TLB shootdown statistics.  (I'm working
> on a patch to implement this on a new machine at SGI.)
> 
> I had planned to display these statistics through /proc
> as in arch/ia64/sn/kernel/sn2/sn2_smp.c (/proc/sgi_sn/ptc_statistics).
> 
> However, considering the general move to reserve /proc for
> process-related things, I thought the community might prefer the
> interface to be in /sys.
> 
> But sysfs has an output buffer restriction of one page, which
> is too restrictive for statistics from very large cpu counts.
> We intend to display about 10 numbers per cpu.
> 
> Besides, the spirit of /sys according to the sysfs.txt documentation:
>     "Attributes should be ... preferably with only one value
>      per file. ... acceptable to express an array of values of the same type."
>   [it also  warns:
>     "... expressing multiple lines of data, ... is heavily frowned upon.
>      Doing these things may get you publically humiliated and your code
>      rewritten without notice."]
> 
> If I break up the statistics files per-cpu, or maybe ranges of
> cpu's, it would create a potentially large number of files in /sys.
> 
> Or, I could stick with a single file in /proc.
> 
> What would you recommend?

TLB shootdowns are in /proc/interrupts at least on x86_64.

Re: [RFC] use of /sys versus /proc

[Robin Holt]

On Sat, May 24, 2008 at 12:47:39AM +0400, Alexey Dobriyan wrote:
> On Fri, May 23, 2008 at 08:12:55AM -0500, Cliff Wickman wrote:
> > I have a need to display TLB shootdown statistics.  (I'm working
> > on a patch to implement this on a new machine at SGI.)
> > 
> > I had planned to display these statistics through /proc
> > as in arch/ia64/sn/kernel/sn2/sn2_smp.c (/proc/sgi_sn/ptc_statistics).
> > 
> > However, considering the general move to reserve /proc for
> > process-related things, I thought the community might prefer the
> > interface to be in /sys.
> > 
> > But sysfs has an output buffer restriction of one page, which
> > is too restrictive for statistics from very large cpu counts.
> > We intend to display about 10 numbers per cpu.
> > 
> > Besides, the spirit of /sys according to the sysfs.txt documentation:
> >     "Attributes should be ... preferably with only one value
> >      per file. ... acceptable to express an array of values of the same type."
> >   [it also  warns:
> >     "... expressing multiple lines of data, ... is heavily frowned upon.
> >      Doing these things may get you publically humiliated and your code
> >      rewritten without notice."]
> > 
> > If I break up the statistics files per-cpu, or maybe ranges of
> > cpu's, it would create a potentially large number of files in /sys.
> > 
> > Or, I could stick with a single file in /proc.
> > 
> > What would you recommend?
> 
> TLB shootdowns are in /proc/interrupts at least on x86_64.

This is a different engine for our UV platform.  Due to the large number
of nodes with many cpus that may need to be invalidated, we have a
special piece of hardware that assists in broadcasts.  Cliff's upcoming
patch will introduce that.  He has written the driver with some built-in
statistics about the use of that hardware.

Thanks,
Robin