Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755587AbcC2Dvu (ORCPT ); Mon, 28 Mar 2016 23:51:50 -0400 Received: from mail113-248.mail.alibaba.com ([205.204.113.248]:55155 "EHLO us-alimail-mta2.hst.scl.en.alidc.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752980AbcC2Dvs (ORCPT ); Mon, 28 Mar 2016 23:51:48 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R681e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03284;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=16;SR=0;TI=SMTPD_----4eWxRWK_1459223447; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Mike Kravetz'" , , , Cc: "'Hugh Dickins'" , "'Naoya Horiguchi'" , "'Kirill A. Shutemov'" , "'David Rientjes'" , "'Dave Hansen'" , "'Thomas Gleixner'" , "'Ingo Molnar'" , "'H. Peter Anvin'" , "'Catalin Marinas'" , "'Will Deacon'" , "'Steve Capper'" , "'Andrew Morton'" References: <1459213970-17957-1-git-send-email-mike.kravetz@oracle.com> <1459213970-17957-2-git-send-email-mike.kravetz@oracle.com> In-Reply-To: <1459213970-17957-2-git-send-email-mike.kravetz@oracle.com> Subject: Re: [RFC PATCH 1/2] mm/hugetlbfs: Attempt PUD_SIZE mapping alignment if PMD sharing enabled Date: Tue, 29 Mar 2016 11:50:47 +0800 Message-ID: <024b01d1896e$2e600e70$8b202b50$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKFNNu6tQLWKGDna4tVYH5zVkQo8QK+QQz+nfJ++SA= Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2214 Lines: 69 > > When creating a hugetlb mapping, attempt PUD_SIZE alignment if the > following conditions are met: > - Address passed to mmap or shmat is NULL > - The mapping is flaged as shared > - The mapping is at least PUD_SIZE in length > If a PUD_SIZE aligned mapping can not be created, then fall back to a > huge page size mapping. > > Signed-off-by: Mike Kravetz > --- > fs/hugetlbfs/inode.c | 29 +++++++++++++++++++++++++++-- > 1 file changed, 27 insertions(+), 2 deletions(-) > > diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c > index 540ddc9..22b2e38 100644 > --- a/fs/hugetlbfs/inode.c > +++ b/fs/hugetlbfs/inode.c > @@ -175,6 +175,17 @@ hugetlb_get_unmapped_area(struct file *file, unsigned long addr, > struct vm_area_struct *vma; > struct hstate *h = hstate_file(file); > struct vm_unmapped_area_info info; > + bool pud_size_align = false; > + unsigned long ret_addr; > + > + /* > + * If PMD sharing is enabled, align to PUD_SIZE to facilitate > + * sharing. Only attempt alignment if no address was passed in, > + * flags indicate sharing and size is big enough. > + */ > + if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) && > + !addr && flags & MAP_SHARED && len >= PUD_SIZE) > + pud_size_align = true; > > if (len & ~huge_page_mask(h)) > return -EINVAL; > @@ -199,9 +210,23 @@ hugetlb_get_unmapped_area(struct file *file, unsigned long addr, > info.length = len; > info.low_limit = TASK_UNMAPPED_BASE; > info.high_limit = TASK_SIZE; > - info.align_mask = PAGE_MASK & ~huge_page_mask(h); > + if (pud_size_align) > + info.align_mask = PAGE_MASK & (PUD_SIZE - 1); > + else > + info.align_mask = PAGE_MASK & ~huge_page_mask(h); > info.align_offset = 0; > - return vm_unmapped_area(&info); > + ret_addr = vm_unmapped_area(&info); > + > + /* > + * If failed with PUD_SIZE alignment, try again with huge page > + * size alignment. > + */ Can we avoid going another round as long as it is a file with the PUD page size? Hillf > + if ((ret_addr & ~PAGE_MASK) && pud_size_align) { > + info.align_mask = PAGE_MASK & ~huge_page_mask(h); > + ret_addr = vm_unmapped_area(&info); > + } > + > + return ret_addr; > } > #endif > > -- > 2.4.3