From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932906AbYEIQig (ORCPT ); Fri, 9 May 2008 12:38:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754900AbYEIQi1 (ORCPT ); Fri, 9 May 2008 12:38:27 -0400 Received: from relay1.sgi.com ([192.48.171.29]:59154 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754563AbYEIQi0 (ORCPT ); Fri, 9 May 2008 12:38:26 -0400 Date: Fri, 9 May 2008 09:38:25 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Linus Torvalds cc: Russ Anderson , linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org, Andrew Morton , Tony Luck Subject: Re: [PATCH 0/3] ia64: Migrate data off physical pages with correctable errors v3 In-Reply-To: Message-ID: References: <20080509150937.GA16523@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 9 May 2008, Linus Torvalds wrote: > So I haven't looked at this a lot, but it strikes me that it look to be > much simple if you were to just increment the page count instead of > playing games in mm/page_alloc.c. We are taking a refcount when isolating the page from the LRU. The problem is that the migration code attempts to free the page. That code could be changed to do something else instead like putting the page on the bad list. > I'm also not really seeing why this triggers on lru_cache_add(), since > that should only happen to new pages anyway. Who does lru_cache_add() on > old pages? Migration code does the adding back to the LRU when migration is complete. So he hooked into that I guess.