[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1007291132210.17734@router.home>
Date: Thu, 29 Jul 2010 11:47:26 -0500 (CDT)
From: Christoph Lameter <cl@...ux-foundation.org>
To: Minchan Kim <minchan.kim@...il.com>
cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Milton Miller <miltonm@....com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Russell King <linux@....linux.org.uk>,
Mel Gorman <mel@....ul.ie>,
Johannes Weiner <hannes@...xchg.org>,
Kukjin Kim <kgene.kim@...sung.com>
Subject: Re: [PATCH] Tight check of pfn_valid on sparsemem - v4
On Fri, 30 Jul 2010, Minchan Kim wrote:
> The thing is valid section also have a invalid memmap.
Oww... . A valid section points to a valid memmap memory block (the page
structs) but the underlying memory pages may not present. So you can check
the (useless) page structs for the page state of the not present pages in
the memory map. If the granularity of the sparsemem mapping is not
sufficient for your purpose then you can change the sparsemem config
(configuration is in arch/<arch>/include/asm/sparsemem.h but does not
exist for arm).
> It means section 0 is an incompletely filled section.
> Nontheless, current pfn_valid of sparsemem checks pfn loosely.
> It checks only mem_section's validation but ARM can free mem_map on hole
> to save memory space. So in above case, pfn on 0x25000000 can pass pfn_valid's
> validation check. It's not what we want.
IMHO ARM should not poke holes in the memmap sections. The guarantee of
the full presence of the section is intentional to avoid having to do
these checks that you are proposing. The page allocator typically expects
to be able to check all page structs in one basic allocation unit.
Also pfn_valid then does not have to touch the pag struct to perform its
function as long as we guarantee the presence of the memmap section.
--
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