linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russ Anderson <rja@sgi.com>
To: haveblue@us.ibm.com (Dave Hansen)
Cc: rja@sgi.com (Russ Anderson),
	rmk+lkml@arm.linux.org.uk (Russell King),
	linux-kernel@vger.kernel.org (Linux Kernel Mailing List)
Subject: Re: [RFC] Linux memory error handling
Date: Mon, 20 Jun 2005 15:42:32 -0500 (CDT)	[thread overview]
Message-ID: <200506202042.j5KKgXKl4801437@clink.americas.sgi.com> (raw)
In-Reply-To: <1118871234.6620.41.camel@localhost> from "Dave Hansen" at Jun 15, 2005 02:33:54 PM

Dave Hansen wrote:
> On Wed, 2005-06-15 at 16:27 -0500, Russ Anderson wrote:
> > How about /sys/devices/system/memory/dimmX with links in
> > /sys/devices/system/node/nodeX/ ?  Does that sound better?
> 
> Much better than /proc :)
> 
> However, we're already using /sys/devices/system/memory/ for memory
> hotplug to represent Linux's view of memory, and which physical
> addresses it is currently using.  I've thought about this before, and I
> think that we may want to have /sys/.../memory/hardware for the DIMM
> information and memory/logical for the memory hotplug controls.

Is there a standard for how to name hardware entries in 
/sys/devices/system (or sysfs in general)?  Seems like this
same general issue would apply to other hardware components,
cpus, nodes, etc.  
 
> One other minor thing.  You might want to think about referring to the
> pieces of memory as things other than DIMMs.  On ppc64, for instance,
> the hypervisor hands off memory in sections called LMBs (logical memory
> blocks), and they're not directly related to any hardware DIMM.  The
> same things will show up in other virtualized environments.

If we're talking about specific hardware entries, it seems like they
should be called what they are.  If we're talking about abstractions,
a more abstract name seems in order.  One of my concerns is mapping 
failures back to hardware components, hence my bias for component names.
Would having /sys/.../memory/LMB on ppc64 to correspond to 
/sys/.../memory/DIMM be a problem?  RAM would be an alternative,
but that could be confused with /sys/block/ram.  :-)

In general, I'm more concerned with getting the necessary functionality
in than what the specific entries are called, so I'll go along with
the consensus.

-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@sgi.com

  reply	other threads:[~2005-06-20 20:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-15 14:30 [RCF] Linux memory error handling Russ Anderson
2005-06-15 15:08 ` Andi Kleen
2005-06-15 16:36   ` Russ Anderson
2005-06-15 15:26 ` Maciej W. Rozycki
2005-06-15 19:46   ` Russell King
2005-06-15 20:28     ` [RFC] " Russ Anderson
2005-06-15 20:45       ` Dave Hansen
2005-06-15 21:27         ` Russ Anderson
2005-06-15 21:33           ` Dave Hansen
2005-06-20 20:42             ` Russ Anderson [this message]
2005-06-20 21:07               ` Dave Hansen
2005-06-15 22:09   ` Russ Anderson
2005-06-16 19:42     ` Maciej W. Rozycki
2005-06-16  1:03   ` [RCF] " Ross Biro
2005-06-15 20:42 ` Joel Schopp
2005-06-16  2:54 ` Wang, Zhenyu

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=200506202042.j5KKgXKl4801437@clink.americas.sgi.com \
    --to=rja@sgi.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).