Tight check of pfn_valid on sparsemem - v4
in [Kernel]
|
From: Christoph Lameter on 28 Jul 2010 13:10 On Thu, 29 Jul 2010, Minchan Kim wrote: > > Simplest scheme would be to clear PageReserved() in all page struct > > associated with valid pages and clear those for page structs that do not > > refer to valid pages. > > I can't understand your words. > Clear PG_resereved in valid pages and invalid pages both? Argh sorry. No. Set PageReserved for pages that do not refer to reserved pages. > I guess your code look like that clear PG_revered on valid memmap > but set PG_reserved on invalid memmap. > Right? Right. > invalid memmap pages will be freed by free_memmap and will be used > on any place. How do we make sure it has PG_reserved? Not present memmap pages make pfn_valid fail already since there is no entry for the page table (vmemmap) or blocks are missing in the sparsemem tables. > Maybe I don't understand your point. I thought we are worrying about holes in the memmap blocks containing page structs. Some page structs point to valid pages and some are not. The invalid page structs need to be marked consistently to allow the check. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Minchan Kim on 28 Jul 2010 19:00 On Wed, Jul 28, 2010 at 12:02:16PM -0500, Christoph Lameter wrote: > On Thu, 29 Jul 2010, Minchan Kim wrote: > > invalid memmap pages will be freed by free_memmap and will be used > > on any place. How do we make sure it has PG_reserved? > > Not present memmap pages make pfn_valid fail already since there is no > entry for the page table (vmemmap) or blocks are missing in the sparsemem > tables. > > > Maybe I don't understand your point. > > I thought we are worrying about holes in the memmap blocks containing page > structs. Some page structs point to valid pages and some are not. The > invalid page structs need to be marked consistently to allow the check. The thing is that memmap pages which contains struct page array on hole will be freed by free_memmap in ARM. Please loot at arch/arm/mm/init.c. And it will be used by page allocator as free pages. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Lameter on 29 Jul 2010 11:50 On Thu, 29 Jul 2010, Minchan Kim wrote: > On Wed, Jul 28, 2010 at 12:02:16PM -0500, Christoph Lameter wrote: > > On Thu, 29 Jul 2010, Minchan Kim wrote: > > > invalid memmap pages will be freed by free_memmap and will be used > > > on any place. How do we make sure it has PG_reserved? > > > > Not present memmap pages make pfn_valid fail already since there is no > > entry for the page table (vmemmap) or blocks are missing in the sparsemem > > tables. > > > > > Maybe I don't understand your point. > > > > I thought we are worrying about holes in the memmap blocks containing page > > structs. Some page structs point to valid pages and some are not. The > > invalid page structs need to be marked consistently to allow the check. > > The thing is that memmap pages which contains struct page array on hole will be > freed by free_memmap in ARM. Please loot at arch/arm/mm/init.c. > And it will be used by page allocator as free pages. Arg thats the solution to the mystery. freememmap() is arm specific hack! Sparsemem allows you to properly handle holes already and then pfn_valid will work correctly. Why are the ways to manage holes in the core not used by arm? sparsemem does a table lookup to determine valid and invalid sections of the memmp. from include/linux/mmzone.h: static inline int pfn_valid(unsigned long pfn) { if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS) return 0; return valid_section(__nr_to_section(pfn_to_section_nr(pfn))); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Minchan Kim on 29 Jul 2010 12:20 On Thu, Jul 29, 2010 at 10:46:13AM -0500, Christoph Lameter wrote: > On Thu, 29 Jul 2010, Minchan Kim wrote: > > > On Wed, Jul 28, 2010 at 12:02:16PM -0500, Christoph Lameter wrote: > > > On Thu, 29 Jul 2010, Minchan Kim wrote: > > > > invalid memmap pages will be freed by free_memmap and will be used > > > > on any place. How do we make sure it has PG_reserved? > > > > > > Not present memmap pages make pfn_valid fail already since there is no > > > entry for the page table (vmemmap) or blocks are missing in the sparsemem > > > tables. > > > > > > > Maybe I don't understand your point. > > > > > > I thought we are worrying about holes in the memmap blocks containing page > > > structs. Some page structs point to valid pages and some are not. The > > > invalid page structs need to be marked consistently to allow the check. > > > > The thing is that memmap pages which contains struct page array on hole will be > > freed by free_memmap in ARM. Please loot at arch/arm/mm/init.c. > > And it will be used by page allocator as free pages. > > Arg thats the solution to the mystery. freememmap() is arm specific hack! > > Sparsemem allows you to properly handle holes already and then pfn_valid > will work correctly. > > Why are the ways to manage holes in the core not used by arm? I did use ARCH_HAS_HOLES_MEMORYMODEL. It is used by only ARM now. If you disable the config, it doesn't affect the core. > > sparsemem does a table lookup to determine valid and invalid sections of > the memmp. > The thing is valid section also have a invalid memmap. Maybe my description isn't enough. Please look at description and following URL. We already confirmed this problem. http://www.spinics.net/lists/arm-kernel/msg92918.html == CUT HERE == Kukjin reported oops happen while he change min_free_kbytes http://www.spinics.net/lists/arm-kernel/msg92894.html It happen by memory map on sparsemem. The system has a memory map following as. section 0 section 1 section 2 0x20000000-0x25000000, 0x40000000-0x50000000, 0x50000000-0x58000000 SECTION_SIZE_BITS 28(256M) 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. -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Lameter on 29 Jul 2010 12:50
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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |