On Thu 12-07-12 12:26:45, Will Deacon wrote: > On Thu, Jul 12, 2012 at 12:16:59PM +0100, Michal Hocko wrote: > > On Wed 11-07-12 18:48:02, Will Deacon wrote: > > > Just to confirm, the following quick hack at least results in the correct > > > flushing for me (on ARM): > > > > > > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > > index e198831..7a7c9d3 100644 > > > --- a/mm/hugetlb.c > > > +++ b/mm/hugetlb.c > > > @@ -1141,6 +1141,7 @@ static struct page *alloc_huge_page(struct > > > vm_area_struct *vma, > > > } > > > > > > set_page_private(page, (unsigned long)spool); > > > + clear_bit(PG_arch_1, &page->flags); > > > > > > vma_commit_reservation(h, vma, addr); > > > > > > > > > > > > The question is whether we should tidy that up for the core code or get > > > architectures to clear the bit in arch_make_huge_pte (which also seems to > > > work). > > > > This should go into arch specific code IMO. Even the page flag name > > suggests this shouldn't be in the base code. > > Well, the comment in linux/page-flags.h does state that: > > * PG_arch_1 is an architecture specific page state bit. The generic code > * guarantees that this bit is cleared for a page when it first is entered > into > * the page cache. > > so it's not completely clear cut that the architecture should be responsible > for clearing this bit when allocating pages from the hugepage pool.
I think the wording is quite clear. It guarantees it gets cleared not clears it. So it is up to an arch specific functions called from the generic code to do that. -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
