Messages in this thread | | | From | Keith Owens <> | Subject | Re: [PATCH] [0/6] HUGETLB memory commitment | Date | Fri, 26 Mar 2004 11:10:44 +1100 |
| |
On Thu, 25 Mar 2004 23:59:21 +0000, Andy Whitcroft <apw@shadowen.org> wrote: >--On 25 March 2004 15:51 -0800 Andrew Morton <akpm@osdl.org> wrote: > >> I think it's simply: >> >> - Make normal overcommit logic skip hugepages completely >> >> - Teach the overcommit_memory=2 logic that hugepages are basically >> "pinned", so subtract them from the arithmetic. >> >> And that's it. The hugepages are semantically quite different from normal >> memory (prefaulted, preallocated, unswappable) and we've deliberately >> avoided pretending otherwise. > >True currently. Though the thread that prompted this was in response to >the time taken for this prefault and for the wish to fault them. > >I'll have a poke about at it and see how small I can make it.
FWIW, lkcd (crash dump) treats hugetlb pages as normal kernel pages and dumps them, which is pointless and wastes a lot of time. To avoid dumping these pages in lkcd, I had to add a PG_hugetlb flag. lkcd runs at the page level, not mm or vma, so VM_hugetlb was not available. In set_hugetlb_mem_size()
for (j = 0; j < (HPAGE_SIZE / PAGE_SIZE); j++) { SetPageReserved(map); SetPageHugetlb(map); map++; }
In dump_base.c, I changed kernel_page(), referenced_page() and unreferenced_page() to test for PageHugetlb() before PageReserved().
Since you are looking at identifying hugetlb pages, could any other code benefit from a PG_hugetlb flag?
- 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/
| |