From: Miaohe Lin <linmiaohe@huawei.com>
To: David Rientjes <rientjes@google.com>
Cc: <akpm@linux-foundation.org>, <mike.kravetz@oracle.com>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] hugetlbfs: show pagesize in unit of GB if possible
Date: Tue, 2 Feb 2021 09:26:03 +0800 [thread overview]
Message-ID: <0c9187f0-39c8-8f7d-79a7-9823cba43c5c@huawei.com> (raw)
In-Reply-To: <c755cad3-1020-46bc-2c4c-7e382ad366f5@google.com>
Hi:
On 2021/2/2 5:31, David Rientjes wrote:
> On Mon, 1 Feb 2021, Miaohe Lin wrote:
>
>>>> Hugepage size in unit of GB is supported. We could show pagesize in unit of
>>>> GB to make it more friendly to read. Also rework the calculation code of
>>>> page size unit to make it more readable.
>>>>
>>>> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
>>>> ---
>>>> fs/hugetlbfs/inode.c | 12 ++++++++----
>>>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
>>>> index 3a08fbae3b53..40a9795f250a 100644
>>>> --- a/fs/hugetlbfs/inode.c
>>>> +++ b/fs/hugetlbfs/inode.c
>>>> @@ -1014,11 +1014,15 @@ static int hugetlbfs_show_options(struct seq_file *m, struct dentry *root)
>>>> if (sbinfo->max_inodes != -1)
>>>> seq_printf(m, ",nr_inodes=%lu", sbinfo->max_inodes);
>>>>
>>>> - hpage_size /= 1024;
>>>> - mod = 'K';
>>>> - if (hpage_size >= 1024) {
>>>> - hpage_size /= 1024;
>>>> + if (hpage_size >= SZ_1G) {
>>>> + hpage_size /= SZ_1G;
>>>> + mod = 'G';
>>>> + } else if (hpage_size >= SZ_1M) {
>>>> + hpage_size /= SZ_1M;
>>>> mod = 'M';
>>>> + } else {
>>>> + hpage_size /= SZ_1K;
>>>> + mod = 'K';
>>>> }
>>>> seq_printf(m, ",pagesize=%lu%c", hpage_size, mod);
>>>> if (spool) {
>>>
>>> NACK, this can break existing userspace parsing.
>>> .
>>>
>>
>> I see. I should take care of this. Many thanks.
>>
>
> Thanks. It's an important point to emphasize because it shows how
> important user-facing interfaces are. Once the hugetlbfs mount options
> are printed in the way they are, it becomes very difficult to change them
> because there can be userspace in the wild that would break as a result.
> This is why it's crucial to be very careful when specifying user-facing
> interfaces the first time so they are extensible.
> .
>
Many thanks for detailed explanation! I will keep this in mind! Thanks again.
prev parent reply other threads:[~2021-02-02 1:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-30 9:03 [PATCH] hugetlbfs: show pagesize in unit of GB if possible Miaohe Lin
2021-01-30 22:07 ` David Rientjes
2021-02-01 1:22 ` Miaohe Lin
2021-02-01 21:31 ` David Rientjes
2021-02-02 1:26 ` 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=0c9187f0-39c8-8f7d-79a7-9823cba43c5c@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 \
--cc=rientjes@google.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;
as well as URLs for NNTP newsgroup(s).