All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Cliff Wickman <cpw@sgi.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] use of /sys versus /proc
Date: Fri, 23 May 2008 15:08:42 -0500	[thread overview]
Message-ID: <20080523200842.GI4287@sgi.com> (raw)
In-Reply-To: <20080523204739.GA15760@martell.zuzino.mipt.ru>

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

      reply	other threads:[~2008-05-23 20:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-23 13:12 [RFC] use of /sys versus /proc Cliff Wickman
2008-05-23 17:19 ` Valdis.Kletnieks
2008-05-23 20:48   ` Cliff Wickman
2008-05-23 20:47 ` Alexey Dobriyan
2008-05-23 20:08   ` Robin Holt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080523200842.GI4287@sgi.com \
    --to=holt@sgi.com \
    --cc=adobriyan@gmail.com \
    --cc=cpw@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.