Messages in this thread | | | Date | Fri, 3 Sep 2010 09:10:03 -0500 (CDT) | From | Christoph Lameter <> | Subject | Re: [PATCH 04/10] hugetlb: hugepage migration core |
| |
On Fri, 3 Sep 2010, Naoya Horiguchi wrote:
> diff --git v2.6.36-rc2/mm/vmscan.c v2.6.36-rc2/mm/vmscan.c > index c391c32..69ce2a3 100644 > --- v2.6.36-rc2/mm/vmscan.c > +++ v2.6.36-rc2/mm/vmscan.c > @@ -40,6 +40,7 @@ > #include <linux/memcontrol.h> > #include <linux/delayacct.h> > #include <linux/sysctl.h> > +#include <linux/hugetlb.h> > > #include <asm/tlbflush.h> > #include <asm/div64.h> > @@ -508,6 +509,10 @@ void putback_lru_page(struct page *page) > > VM_BUG_ON(PageLRU(page)); > > + if (PageHuge(page)) { > + put_page(page); > + return; > + } > redo: > ClearPageUnevictable(page); > > @@ -1112,7 +1117,9 @@ int isolate_lru_page(struct page *page) > { > int ret = -EBUSY; > > - if (PageLRU(page)) { > + if (PageHuge(page) && get_page_unless_zero(compound_head(page))) > + ret = 0; > + else if (PageLRU(page)) { > struct zone *zone = page_zone(page); > > spin_lock_irq(&zone->lru_lock); >
Huge pages are not on the LRU right? So why use the lru functions for them and then not use the lru? Its a bit stranger. The caller must aware of the different handling of huge pages since there is no toying around with the lru. So just have the caller do a put or get page instead.
| |