linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Miaohe Lin <linmiaohe@huawei.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: Mon, 1 Feb 2021 13:31:53 -0800 (PST)	[thread overview]
Message-ID: <c755cad3-1020-46bc-2c4c-7e382ad366f5@google.com> (raw)
In-Reply-To: <24ab70d6-1d23-d118-f1e7-473f01615dcc@huawei.com>

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.


  reply	other threads:[~2021-02-01 21:31 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 [this message]
2021-02-02  1:26       ` Miaohe Lin

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=c755cad3-1020-46bc-2c4c-7e382ad366f5@google.com \
    --to=rientjes@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --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;
as well as URLs for NNTP newsgroup(s).