The patch titled Subject: hugetlbfs: dirty pages as they are added to pagecache has been added to the -mm tree. Its filename is hugetlbfs-dirty-pages-as-they-are-added-to-pagecache-v2.patch

This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/hugetlbfs-dirty-pages-as-they-are-a... and later at http://ozlabs.org/~akpm/mmotm/broken-out/hugetlbfs-dirty-pages-as-they-are-a...

Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next and is updated there every 3-4 working days

------------------------------------------------------ From: Mike Kravetz mike.kravetz@oracle.com Subject: hugetlbfs: dirty pages as they are added to pagecache

Some test systems were experiencing negative huge page reserve counts and incorrect file block counts. This was traced to /proc/sys/vm/drop_caches removing clean pages from hugetlbfs file pagecaches. When non-hugetlbfs explicit code removes the pages, the appropriate accounting is not performed.

This can be recreated as follows: fallocate -l 2M /dev/hugepages/foo echo 1 > /proc/sys/vm/drop_caches fallocate -l 2M /dev/hugepages/foo grep -i huge /proc/meminfo AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 2048 HugePages_Free: 2047 HugePages_Rsvd: 18446744073709551615 HugePages_Surp: 0 Hugepagesize: 2048 kB Hugetlb: 4194304 kB ls -lsh /dev/hugepages/foo 4.0M -rw-r--r--. 1 root root 2.0M Oct 17 20:05 /dev/hugepages/foo

To address this issue, dirty pages as they are added to pagecache. This can easily be reproduced with fallocate as shown above. Read faulted pages will eventually end up being marked dirty. But there is a window where they are clean and could be impacted by code such as drop_caches. So, just dirty them all as they are added to the pagecache.

Link: http://lkml.kernel.org/r/b5be45b8-5afe-56cd-9482-28384699a049@oracle.com Fixes: 6bda666a03f0 ("hugepages: fold find_or_alloc_pages into huge_no_page()") Signed-off-by: Mike Kravetz mike.kravetz@oracle.com Acked-by: Mihcla Hocko mhocko@suse.com Reviewed-by: Khalid Aziz khalid.aziz@oracle.com Cc: Hugh Dickins hughd@google.com Cc: Naoya Horiguchi n-horiguchi@ah.jp.nec.com Cc: "Aneesh Kumar K . V" aneesh.kumar@linux.vnet.ibm.com Cc: Andrea Arcangeli aarcange@redhat.com Cc: "Kirill A . Shutemov" kirill.shutemov@linux.intel.com Cc: Davidlohr Bueso dave@stgolabs.net Cc: Alexander Viro viro@zeniv.linux.org.uk Cc: stable@vger.kernel.org Signed-off-by: Andrew Morton akpm@linux-foundation.org ---

mm/hugetlb.c | 6 ++++++ 1 file changed, 6 insertions(+)

--- a/mm/hugetlb.c~hugetlbfs-dirty-pages-as-they-are-added-to-pagecache-v2 +++ a/mm/hugetlb.c @@ -3690,6 +3690,12 @@ int huge_add_to_page_cache(struct page * return err; ClearPagePrivate(page);

+ /* + * set page dirty so that it will not be removed from cache/file + * by non-hugetlbfs specific code paths. + */ + set_page_dirty(page); + spin_lock(&inode->i_lock); inode->i_blocks += blocks_per_huge_page(h); spin_unlock(&inode->i_lock); _

Patches currently in -mm which might be from mike.kravetz@oracle.com are

hugetlbfs-dirty-pages-as-they-are-added-to-pagecache-v2.patch hugetlbfs-dirty-pages-as-they-are-added-to-pagecache.patch