Thread (17 messages) 17 messages, 4 authors, 2012-08-16

Re: [PATCH] mm: hugetlb: flush dcache before returning zeroed huge page to userspace

From: Will Deacon <hidden>
Date: 2012-07-12 11:27:08
Also in: linux-mm, lkml

On Thu, Jul 12, 2012 at 12:16:59PM +0100, Michal Hocko wrote:
On Wed 11-07-12 18:48:02, Will Deacon wrote:
quoted
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.

Will

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help