From: Ingo Molnar <mingo@kernel.org>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org,
Hugh Dickins <hughd@google.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Hillf Danton <hillf.zj@alibaba-inc.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Steve Capper <steve.capper@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 2/2] x86/hugetlb: Attempt PUD_SIZE mapping alignment if PMD sharing enabled
Date: Tue, 29 Mar 2016 10:35:10 +0200 [thread overview]
Message-ID: <20160329083510.GA27941@gmail.com> (raw)
In-Reply-To: <1459213970-17957-3-git-send-email-mike.kravetz@oracle.com>
* Mike Kravetz <mike.kravetz@oracle.com> wrote:
> 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 <mike.kravetz@oracle.com>
> ---
> arch/x86/mm/hugetlbpage.c | 64 ++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
> index 42982b2..4f53af5 100644
> --- a/arch/x86/mm/hugetlbpage.c
> +++ b/arch/x86/mm/hugetlbpage.c
> @@ -78,14 +78,39 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,
> {
> 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;
>
> info.flags = 0;
> info.length = len;
> info.low_limit = current->mm->mmap_legacy_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.
> + */
> + if ((ret_addr & ~PAGE_MASK) && pud_size_align) {
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + ret_addr = vm_unmapped_area(&info);
> + }
So AFAICS 'ret_addr' is either page aligned, or is an error code. Wouldn't it be a
lot easier to read to say:
if ((long)ret_addr > 0 && pud_size_align) {
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
ret_addr = vm_unmapped_area(&info);
}
return ret_addr;
to make it clear that it's about error handling, not some alignment
requirement/restriction?
> /*
> + * If failed with PUD_SIZE alignment, try again with huge page
> + * size alignment.
> + */
> + if ((addr & ~PAGE_MASK) && pud_size_align) {
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + addr = vm_unmapped_area(&info);
> + }
Ditto.
> addr = vm_unmapped_area(&info);
> +
> + /*
> + * If failed again with PUD_SIZE alignment, finally try with
> + * huge page size alignment.
> + */
> + if (addr & ~PAGE_MASK) {
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + addr = vm_unmapped_area(&info);
Ditto.
Thanks,
Ingo
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org,
Hugh Dickins <hughd@google.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Hillf Danton <hillf.zj@alibaba-inc.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Steve Capper <steve.capper@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 2/2] x86/hugetlb: Attempt PUD_SIZE mapping alignment if PMD sharing enabled
Date: Tue, 29 Mar 2016 10:35:10 +0200 [thread overview]
Message-ID: <20160329083510.GA27941@gmail.com> (raw)
In-Reply-To: <1459213970-17957-3-git-send-email-mike.kravetz@oracle.com>
* Mike Kravetz <mike.kravetz@oracle.com> wrote:
> 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 <mike.kravetz@oracle.com>
> ---
> arch/x86/mm/hugetlbpage.c | 64 ++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 61 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
> index 42982b2..4f53af5 100644
> --- a/arch/x86/mm/hugetlbpage.c
> +++ b/arch/x86/mm/hugetlbpage.c
> @@ -78,14 +78,39 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,
> {
> 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;
>
> info.flags = 0;
> info.length = len;
> info.low_limit = current->mm->mmap_legacy_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.
> + */
> + if ((ret_addr & ~PAGE_MASK) && pud_size_align) {
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + ret_addr = vm_unmapped_area(&info);
> + }
So AFAICS 'ret_addr' is either page aligned, or is an error code. Wouldn't it be a
lot easier to read to say:
if ((long)ret_addr > 0 && pud_size_align) {
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
ret_addr = vm_unmapped_area(&info);
}
return ret_addr;
to make it clear that it's about error handling, not some alignment
requirement/restriction?
> /*
> + * If failed with PUD_SIZE alignment, try again with huge page
> + * size alignment.
> + */
> + if ((addr & ~PAGE_MASK) && pud_size_align) {
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + addr = vm_unmapped_area(&info);
> + }
Ditto.
> addr = vm_unmapped_area(&info);
> +
> + /*
> + * If failed again with PUD_SIZE alignment, finally try with
> + * huge page size alignment.
> + */
> + if (addr & ~PAGE_MASK) {
> + info.align_mask = PAGE_MASK & ~huge_page_mask(h);
> + addr = vm_unmapped_area(&info);
Ditto.
Thanks,
Ingo
next prev parent reply other threads:[~2016-03-29 8:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 1:12 [RFC PATCH 0/2] hugetlb: If PMD sharing is possible, align to PUD_SIZE Mike Kravetz
2016-03-29 1:12 ` Mike Kravetz
2016-03-29 1:12 ` [RFC PATCH 1/2] mm/hugetlbfs: Attempt PUD_SIZE mapping alignment if PMD sharing enabled Mike Kravetz
2016-03-29 1:12 ` Mike Kravetz
2016-03-29 3:50 ` Hillf Danton
2016-03-29 3:50 ` Hillf Danton
2016-03-29 16:29 ` Mike Kravetz
2016-03-29 16:29 ` Mike Kravetz
2016-03-31 2:18 ` Naoya Horiguchi
2016-03-31 2:18 ` Naoya Horiguchi
2016-03-31 16:45 ` Mike Kravetz
2016-03-31 16:45 ` Mike Kravetz
2016-03-29 1:12 ` [RFC PATCH 2/2] x86/hugetlb: " Mike Kravetz
2016-03-29 1:12 ` Mike Kravetz
2016-03-29 8:35 ` Ingo Molnar [this message]
2016-03-29 8:35 ` Ingo Molnar
2016-03-29 17:05 ` Mike Kravetz
2016-03-29 17:05 ` Mike Kravetz
2016-03-31 2:26 ` Naoya Horiguchi
2016-03-31 2:26 ` Naoya Horiguchi
2016-03-31 11:38 ` Ingo Molnar
2016-03-31 11:38 ` Ingo Molnar
2016-03-31 16:32 ` Mike Kravetz
2016-03-31 16:32 ` Mike Kravetz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160329083510.GA27941@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=hillf.zj@alibaba-inc.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=mingo@redhat.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=rientjes@google.com \
--cc=steve.capper@linaro.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.