From: Miaohe Lin <linmiaohe@huawei.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] hugetlbfs: make hugepage size conversion more readable
Date: Fri, 22 Jan 2021 14:12:11 +0800 [thread overview]
Message-ID: <02bc3a85-ca7a-e8a3-587b-7341c390ac74@huawei.com> (raw)
In-Reply-To: <9696d9e0-48d7-871c-6ec0-ba6a31c346bd@oracle.com>
Hi:
On 2021/1/22 13:02, Mike Kravetz wrote:
> On 1/21/21 5:42 PM, Miaohe Lin wrote:
>> Hi:
>> On 2021/1/22 3:00, Mike Kravetz wrote:
>>> On 1/20/21 1:23 AM, Miaohe Lin wrote:
>>>> The calculation 1U << (h->order + PAGE_SHIFT - 10) is actually equal to
>>>> (PAGE_SHIFT << (h->order)) >> 10. So we can make it more readable by
>>>> replace it with huge_page_size(h) / SZ_1K.
>>>>
>>>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
>>>> ---
>>>> fs/hugetlbfs/inode.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>>>> index 25c1857ff45d..f94b8f6553fa 100644
>>>> --- a/fs/hugetlbfs/inode.c
>>>> +++ b/fs/hugetlbfs/inode.c
>>>> @@ -1519,8 +1519,8 @@ static struct vfsmount *__init mount_one_hugetlbfs(struct hstate *h)
>>>> put_fs_context(fc);
>>>> }
>>>> if (IS_ERR(mnt))
>>>> - pr_err("Cannot mount internal hugetlbfs for page size %uK",
>>>> - 1U << (h->order + PAGE_SHIFT - 10));
>>>> + pr_err("Cannot mount internal hugetlbfs for page size %luK",
>>>> + huge_page_size(h) / SZ_1K);
>>>
>>> I appreciate the effort to make the code more readable. The existing
>>> calculation does take a minute to understand. However, it is correct and
>>> anyone modifying the code should be able to understand.
>>>
>>> With my compiler, your proposed change adds an additional instruction to
>>> the routine mount_one_hugetlbfs. I know this is not significant, but still
>>
>> I thought compiler would generate the same code...
>>
>>> it does increase the kernel size for a change that is of questionable value.
>>>
>>> In the kernel, size in KB is often calculated as (size << (PAGE_SHIFT - 10)).
>>> If you change the calculation in the hugetlb code to be:
>>>> huge_page_size(h) << (PAGE_SHIFT - 10)
>>
>> I'am sorry but this looks not really correct. I think the calculation shoud be
>> huge_page_size(h) >> 10. What do you think?
>
> My bad! I was looking at code that converts page counts to KB. Sorry.
>
> Yes, huge_page_size(h) >> 10 is correct.
>
So I will send v2 with this change. Many thanks.
prev parent reply other threads:[~2021-01-22 6:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 9:23 Miaohe Lin
2021-01-21 19:00 ` Mike Kravetz
2021-01-22 1:42 ` Miaohe Lin
2021-01-22 5:02 ` Mike Kravetz
2021-01-22 6:12 ` Miaohe Lin [this message]
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=02bc3a85-ca7a-e8a3-587b-7341c390ac74@huawei.com \
--to=linmiaohe@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox