linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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.


      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).