From: Russ Anderson <rja@sgi.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Tony Luck <tony.luck@intel.com>,
Christoph Lameter <clameter@sgi.com>
Subject: Re: [PATCH 3/3] ia64: Call migration code on correctable errors v2
Date: Fri, 2 May 2008 13:50:30 -0500 [thread overview]
Message-ID: <20080502185030.GH7246@sgi.com> (raw)
In-Reply-To: <87fxt0vbu4.fsf@basil.nowhere.org>
On Fri, May 02, 2008 at 07:45:55PM +0200, Andi Kleen wrote:
> Russ Anderson <rja@sgi.com> writes:
>
> > Migrate data off pages with correctable memory errors. This patch is the
> > ia64 specific piece. It connects the CPE handler to the page migration
> > code. It is implemented as a kernel loadable module, similar to the mca
> > recovery code (mca_recovery.ko). This allows the feature to be turned off
> > by uninstalling the module. Creates /proc/badram to display bad page
> > information and free bad pages.
>
> How do you know what pages have excessive errors? And how is excessive defined?
> Surely you don't keep a per page error count? It's unclear from your patch.
The code migrates on the first correctable error on a page, so "excessive"
is one. Yes, keeping a per page count gets problematic, especially as
memories get larger. The issue of the right metric for when to migrate
will always be debatable and the "right" answer likely will depend on
the physical memory technology.
> Anyways I don't think this should be ia64 specific, but generic code.
The actual migration code is generic, in mm/migrate.c.
The ia64 kernel module piece is very arch specific. It ties into the
ia64 CPE handler. It gets the page address from the CPE record, based
on the ia64 error handling spec. Each arch will have a different way of
determining the physical address of the correctable error (for example).
> I also have my doubts about making such small code subsystems modules. Modules
> always get rounded to pages so it ultimatively just wastes memory.
CONFIG_IA64_CPE_MIGRATE=m builds it as module.
CONFIG_IA64_CPE_MIGRATE=y builds it as part of the kernel.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@sgi.com
next prev parent reply other threads:[~2008-05-02 18:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-02 0:44 [PATCH 3/3] ia64: Call migration code on correctable errors v2 Russ Anderson
2008-05-02 1:22 ` Christoph Lameter
2008-05-02 2:43 ` Russ Anderson
2008-05-02 9:58 ` Pekka Enberg
2008-05-02 16:40 ` Russ Anderson
2008-05-02 16:57 ` Pekka J Enberg
2008-05-02 17:30 ` Russ Anderson
2008-05-02 17:45 ` Andi Kleen
2008-05-02 18:50 ` Russ Anderson [this message]
2008-05-02 19:33 ` Andi Kleen
2008-05-02 20:27 ` Russ Anderson
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=20080502185030.GH7246@sgi.com \
--to=rja@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=clameter@sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox