All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Steiner <steiner@sgi.com>
To: Roland Dreier <rdreier@cisco.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, mingo@elte.hu,
	tglx@linutronix.de, holt@sgi.com, andrea@qumranet.com
Subject: Re: [patch 09/11] GRU Driver - /proc interfaces
Date: Mon, 9 Jun 2008 17:11:06 -0500	[thread overview]
Message-ID: <20080609221105.GA20211@sgi.com> (raw)
In-Reply-To: <adaskvm70qp.fsf@cisco.com>

On Mon, Jun 09, 2008 at 02:32:46PM -0700, Roland Dreier wrote:
>  > This file externalizes some GRU state & statistics to the user using the /proc
>  > file system.
> 
> We don't put stuff like this in /proc any more.  Depending on how the
> data will be used, either debugfs or a bunch of sysfs attributes would
> be typical ways to export it.

I was afraid of that. The data is not just for debugging. The info
must be available in standard production systems. So debugfs is not
appropriate.

Can you give me a pointer to a driver to use as a prototype
for /sys information.

 The GRU driver currently generates files that look like:

	
# cat /proc/gru/statistics
              11 vdata_free
              13 gts_alloc
              11 gts_free
              13 assign_context
              11 free_context
              13 load_context
              11 unload_context
              13 nopfn
              13 asid_new
               2 asid_next
             230 intr
              24 call_os
              13 set_task_slice
              38 migrate_check
             230 tlb_dropin
              12 tlb_dropin_fail_upm
             ....


# cat /proc/gru/gru_status
#  gid  nid    ctx   cbr   dsr     ctx   cbr   dsr
#             busy  busy  busy    free  free  free
     0    0      2     4  4096      14   124 28672
     1    0      1     2  1024      15   126 31744
     2    1      0     0     0      16   128 32768
     3    1      1     2  1024      15   126 31744
     ...


AFAICT, this is not a format that is compatible with the /sys guidelines of 1 value
per file.

A system can have 1000's of GRU chiplets. Having separate collection of files for
each set of metrics is clumsy. What other drivers have similar issues. I'll
gladly copy whatever makes sense.


--- jack

  reply	other threads:[~2008-06-09 22:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-09 21:10 [patch 00/11] GRU Driver steiner
2008-06-09 21:10 ` [patch 01/11] GRU Driver - hardware data structures steiner
2008-06-09 22:52   ` Andrew Morton
2008-06-10  4:07     ` Andi Kleen
2008-06-11 18:57     ` Jack Steiner
2008-06-09 21:10 ` [patch 02/11] GRU Driver - GRU instructions & macros steiner
2008-06-09 21:10 ` [patch 03/11] GRU Driver - driver internal header files steiner
2008-06-09 21:38   ` Roland Dreier
2008-06-10 14:57     ` Jack Steiner
2008-06-09 21:10 ` [patch 04/11] GRU Driver - kernel services " steiner
2008-06-09 21:10 ` [patch 05/11] GRU Driver - driver initialization, file & vma ops steiner
2008-06-09 21:10 ` [patch 06/11] GRU Driver - page faults & exceptions steiner
2008-06-09 21:10 ` [patch 07/11] GRU Driver - kernel services provide by driver steiner
2008-06-09 21:10 ` [patch 08/11] GRU Driver - resource management steiner
2008-06-09 21:10 ` [patch 09/11] GRU Driver - /proc interfaces steiner
2008-06-09 21:32   ` Roland Dreier
2008-06-09 22:11     ` Jack Steiner [this message]
2008-06-10 14:20       ` Roland Dreier
2008-06-09 21:10 ` [patch 10/11] GRU Driver - TLB flushing, MMUOPS callouts steiner
2008-06-09 21:10 ` [patch 11/11] GRU Driver - makefile & Kconfig file changes steiner
2008-06-09 21:35   ` Roland Dreier
2008-06-10 14:41     ` Jack Steiner
2008-06-12 13:27 ` [patch 00/11] GRU Driver Ingo Molnar
2008-06-12 14:05   ` Jack Steiner
2008-06-12 18:03     ` Andrew Morton
2008-06-12 20:52       ` Jack Steiner

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=20080609221105.GA20211@sgi.com \
    --to=steiner@sgi.com \
    --cc=akpm@osdl.org \
    --cc=andrea@qumranet.com \
    --cc=holt@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rdreier@cisco.com \
    --cc=tglx@linutronix.de \
    /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.