[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200904080543.16454.ioe-lkml@rameria.de>
Date: Wed, 8 Apr 2009 05:43:15 +0200
From: Ingo Oeser <ioe-lkml@...eria.de>
To: Russ Anderson <rja@....com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org,
Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH 1/2] Avoid putting a bad page back on the LRU
Hi Russ,
On Wednesday 08 April 2009, Russ Anderson wrote:
> --- linux-next.orig/mm/migrate.c 2009-04-07 18:32:12.781949840 -0500
> +++ linux-next/mm/migrate.c 2009-04-07 18:34:19.169736260 -0500
> @@ -693,6 +696,26 @@ unlock:
> * restored.
> */
> list_del(&page->lru);
> +#ifdef CONFIG_MEMORY_FAILURE
> + if (PagePoison(page)) {
> + if (rc == 0)
> + /*
> + * A page with a memory error that has
> + * been migrated will not be moved to
> + * the LRU.
> + */
> + goto move_newpage;
> + else
> + /*
> + * The page failed to migrate and will not
> + * be added to the bad page list. Clearing
> + * the error bit will allow another attempt
> + * to migrate if it gets another correctable
> + * error.
> + */
> + ClearPagePoison(page);
Clearing the flag doesn't change the fact, that this page is representing
permanently bad RAM.
What about removing it from the LRU and adding it to a bad RAM list in every case?
After hot swapping the physical RAM banks it could be moved back, not before.
Best Regards
Ingo Oeser
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists