lkml.org 
[lkml]   [2009]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [RFC][PATCH] proc: export more page flags in /proc/kpageflags (take 3)
On Thu, Apr 23, 2009 at 04:54:06PM +0800, Andi Kleen wrote:
> > Good idea.
> >
> > Would you recommend a good way to identify huge pages?
> > Test by page order, or by (dtor == free_huge_page)?
>
> That doesn't work for GB pages. The best way would be to make
> slub stop using it and then check for compound, but I don't know what
> this implies. Otherwise would need some other way, perhaps a new
> flag?

Or play the following trick? :-)

This helps hide the internal compound page consumers(SLAB/SLUB/... and
loads of device drivers) to user space. However there are still huge
pages of different orders(IA64?). Does this make a good reason for
exporting both HEAD/TAIL flags, instead of a combined COMPOUND flag?

Thanks,
Fengguang
---

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c722aa6..7d0bd0d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -298,6 +298,14 @@ void prep_compound_page(struct page *page, unsigned long order)
}
}

+/*
+ * This function helps distinguish gigantic pages from normal compound pages.
+ */
+static void free_gigantic_page(struct page *page)
+{
+ __free_pages_ok(page, compound_order(page));
+}
+
#ifdef CONFIG_HUGETLBFS
void prep_compound_gigantic_page(struct page *page, unsigned long order)
{
@@ -305,7 +313,7 @@ void prep_compound_gigantic_page(struct page *page, unsigned long order)
int nr_pages = 1 << order;
struct page *p = page + 1;

- set_compound_page_dtor(page, free_compound_page);
+ set_compound_page_dtor(page, free_gigantic_page);
set_compound_order(page, order);
__SetPageHead(page);
for (i = 1; i < nr_pages; i++, p = mem_map_next(p, page, i)) {

\
 
 \ /
  Last update: 2009-04-23 13:25    [W:1.297 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site