Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756435Ab1EAP3M (ORCPT ); Sun, 1 May 2011 11:29:12 -0400 Received: from mail-qw0-f46.google.com ([209.85.216.46]:61283 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753157Ab1EAP3L convert rfc822-to-8bit (ORCPT ); Sun, 1 May 2011 11:29:11 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kaPGNhfyYqHXlZitkhQp9QSN+3Q1fcQvrUP1M5sIGc2hEo+W/9r3OIW/uWnQGBNr2p U69f7HwenUuildfpPiXLrdDnWcPU9EkiEoqq8pAYBh7Pdjs+ZaRukbUMqSoMxgXIW7WM lQYbDHRwawcHozkQ5/DfbngnrNkc0us9DmNXo= MIME-Version: 1.0 In-Reply-To: <20110501224844.75EC.A69D9226@jp.fujitsu.com> References: <51e7412097fa62f86656c77c1934e3eb96d5eef6.1303833417.git.minchan.kim@gmail.com> <20110428110623.GU4658@suse.de> <20110501224844.75EC.A69D9226@jp.fujitsu.com> Date: Mon, 2 May 2011 00:29:10 +0900 Message-ID: Subject: Re: [RFC 6/8] In order putback lru core From: Minchan Kim To: KOSAKI Motohiro Cc: Mel Gorman , Andrew Morton , linux-mm , LKML , Christoph Lameter , Johannes Weiner , KAMEZAWA Hiroyuki , Rik van Riel , Andrea Arcangeli Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2730 Lines: 69 On Sun, May 1, 2011 at 10:47 PM, KOSAKI Motohiro wrote: >> > +/* This structure is used for keeping LRU ordering of isolated page */ >> > +struct pages_lru { >> > +        struct page *page;      /* isolated page */ >> > +        struct page *prev_page; /* previous page of isolate page as LRU order */ >> > +        struct page *next_page; /* next page of isolate page as LRU order */ >> > +        struct list_head lru; >> > +}; >> >  /* >> >> So this thing has to be allocated from somewhere. We can't put it >> on the stack as we're already in danger there so we must be using >> kmalloc. In the reclaim paths, this should be avoided obviously. >> For compaction, we might hurt the compaction success rates if pages >> are pinned with control structures. It's something to be wary of. >> >> At LSF/MM, I stated a preference for swapping the source and >> destination pages in the LRU. This unfortunately means that the LRU >> now contains a page in the process of being migrated to and the backout >> paths for migration failure become a lot more complex. Reclaim should >> be ok as it'll should fail to lock the page and recycle it in the list. >> This avoids allocations but I freely admit that I'm not in the position >> to implement such a thing right now :( > > I like swaping to fake page. one way pointer might become dangerous. vmscan can > detect fake page and ignore it. I guess it means swapping between migrated-from page and migrated-to page. Right? If so, migrated-from page is already removed from LRU list and migrated-to page isn't LRU as it's page allocated newly so they don't have any LRU information. How can we swap them? We need space keeps LRU information before removing the page from LRU list. :( Could you explain in detail about swapping if I miss something? About one way pointer, I think it's no problem. Worst case I imagine is to put the page in head of LRU list. It means it's same issue now. So it doesn't make worse than now. > > ie, > is_fake_page(page) > { >        if (is_stack_addr((void*)page)) >                return true; >        return false; > } > > Also, I like to use stack rather than kmalloc in compaction. > Compaction is a procedure of reclaim. As you know, we had a problem about using of stack during reclaim path. I admit kmalloc-thing isn't good. I will try to solve the issue as TODO. Thanks for the review, KOSAKI. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/