Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752681Ab0GNHoK (ORCPT ); Wed, 14 Jul 2010 03:44:10 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:60724 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751275Ab0GNHoH (ORCPT ); Wed, 14 Jul 2010 03:44:07 -0400 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Date: Wed, 14 Jul 2010 16:39:16 +0900 From: KAMEZAWA Hiroyuki To: Minchan Kim Cc: Dave Hansen , Johannes Weiner , linux@arm.linux.org.uk, Yinghai Lu , "H. Peter Anvin" , Andrew Morton , Shaohua Li , Yakui Zhao , linux-kernel@vger.kernel.org, linux-mm@kvack.org, arm-kernel@lists.infradead.org, kgene.kim@samsung.com, Mel Gorman Subject: Re: [RFC] Tight check of pfn_valid on sparsemem Message-Id: <20100714163916.95afaf92.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <20100712155348.GA2815@barrios-desktop> <20100713093006.GB14504@cmpxchg.org> <20100713154335.GB2815@barrios-desktop> <1279038933.10995.9.camel@nimitz> <20100713164423.GC2815@barrios-desktop> <20100714092301.69e7e628.kamezawa.hiroyu@jp.fujitsu.com> <20100714161045.ef028769.kamezawa.hiroyu@jp.fujitsu.com> Organization: FUJITSU Co. LTD. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 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: 3477 Lines: 85 On Wed, 14 Jul 2010 16:35:22 +0900 Minchan Kim wrote: > On Wed, Jul 14, 2010 at 4:10 PM, KAMEZAWA Hiroyuki > wrote: > > On Wed, 14 Jul 2010 15:44:41 +0900 > > Minchan Kim wrote: > > > >> Hi, Kame. > >> > >> On Wed, Jul 14, 2010 at 9:23 AM, KAMEZAWA Hiroyuki > >> wrote: > >> > On Wed, 14 Jul 2010 01:44:23 +0900 > >> > Minchan Kim wrote: > >> > > >> >> > If you _really_ can't make the section size smaller, and the vast > >> >> > majority of the sections are fully populated, you could hack something > >> >> > in.  We could, for instance, have a global list that's mostly readonly > >> >> > which tells you which sections need to be have their sizes closely > >> >> > inspected.  That would work OK if, for instance, you only needed to > >> >> > check a couple of memory sections in the system.  It'll start to suck if > >> >> > you made the lists very long. > >> >> > >> >> Thanks for advise. As I say, I hope Russell accept 16M section. > >> >> > >> > > >> > It seems what I needed was good sleep.... > >> > How about this if 16M section is not acceptable ? > >> > > >> > == NOT TESTED AT ALL, EVEN NOT COMPILED == > >> > > >> > register address of mem_section to memmap itself's page struct's pg->private field. > >> > This means the page is used for memmap of the section. > >> > Otherwise, the page is used for other purpose and memmap has a hole. > >> > >> It's a very good idea. :) > >> But can this handle case that a page on memmap pages have struct page > >> descriptor of hole? > >> I mean one page can include 128 page descriptor(4096 / 32). > > yes. > > > >> In there, 64 page descriptor is valid but remain 64 page descriptor is on hole. > >> In this case, free_memmap doesn't free the page. > > > > yes. but in that case, there are valid page decriptor for 64pages of holes. > > pfn_valid() should return true but PG_reserved is set. > > (This is usual behavior.) > > > > My intention is that > > > >  - When all 128 page descriptors are unused, free_memmap() will free it. > >   In that case, clear page->private of a page for freed page descriptors. > > > >  - When some of page descriptors are used, free_memmap() can't free it > >   and page->private points to &mem_section. We may have memmap for memory > >   hole but pfn_valid() is a function to check there is memmap or not. > >   The bahavior of pfn_valid() is valid. > >   Anyway, you can't free only half of page. > > Okay. I missed PageReserved. > Your idea seems to be good. :) > > I looked at pagetypeinfo_showblockcount_print. > It doesn't check PageReserved. Instead of it, it does ugly memmap_valid_within. > Can't we remove it and change it with PageReserved? > maybe. but I'm not sure how many archs uses CONFIG_ARCH_HAS_HOLES_MEMORYMODEL. Because my idea requires to add arch-dependent hook, enhancement of pfn_valid() happens only when an arch supports it. So, you may need a conservative path. Anyway, I can't test the patch by myself. So, I pass ball to ARM guys. Feel free to reuse my idea if you like. Signed-off-by: KAMEZAWA Hiroyuki Thanks, -Kame -- 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/