From: Mike Kravetz <mike.kravetz@oracle.com>
To: Hillf Danton <hillf.zj@alibaba-inc.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: 'Hugh Dickins' <hughd@google.com>,
'Naoya Horiguchi' <n-horiguchi@ah.jp.nec.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 1/2] mm/hugetlbfs: Attempt PUD_SIZE mapping alignment if PMD sharing enabled
Date: Tue, 29 Mar 2016 09:29:36 -0700 [thread overview]
Message-ID: <56FAAD70.1020806@oracle.com> (raw)
In-Reply-To: <024b01d1896e$2e600e70$8b202b50$@alibaba-inc.com>
On 03/28/2016 08:50 PM, Hillf Danton 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>
>> ---
>> 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?
Yes, that brings up a good point.
Since we only do PMD sharing with PMD_SIZE huge pages, that should be
part of the check as to whether we try PUD_SIZE alignment. The initial
check should be expanded as follows:
if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) && !addr &&
flags & MAP_SHARED && huge_page_size(h) == PMD_SIZE && len >= PUD_SIZE)
pud_size_align = true;
In that case, pud_size_align remains false and we do not retry.
--
Mike Kravetz
>
> 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
>
--
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: Mike Kravetz <mike.kravetz@oracle.com>
To: Hillf Danton <hillf.zj@alibaba-inc.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: "'Hugh Dickins'" <hughd@google.com>,
"'Naoya Horiguchi'" <n-horiguchi@ah.jp.nec.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 1/2] mm/hugetlbfs: Attempt PUD_SIZE mapping alignment if PMD sharing enabled
Date: Tue, 29 Mar 2016 09:29:36 -0700 [thread overview]
Message-ID: <56FAAD70.1020806@oracle.com> (raw)
In-Reply-To: <024b01d1896e$2e600e70$8b202b50$@alibaba-inc.com>
On 03/28/2016 08:50 PM, Hillf Danton 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>
>> ---
>> 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?
Yes, that brings up a good point.
Since we only do PMD sharing with PMD_SIZE huge pages, that should be
part of the check as to whether we try PUD_SIZE alignment. The initial
check should be expanded as follows:
if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) && !addr &&
flags & MAP_SHARED && huge_page_size(h) == PMD_SIZE && len >= PUD_SIZE)
pud_size_align = true;
In that case, pud_size_align remains false and we do not retry.
--
Mike Kravetz
>
> 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
>
next prev parent reply other threads:[~2016-03-29 16:30 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 [this message]
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
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=56FAAD70.1020806@oracle.com \
--to=mike.kravetz@oracle.com \
--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=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.