From: Greg KH <gregkh@linuxfoundation.org>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Hui Su <sh_def@163.com>,
rafael@kernel.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm/hugetable.c: align some prints
Date: Tue, 27 Oct 2020 07:14:38 +0100 [thread overview]
Message-ID: <20201027061438.GA206502@kroah.com> (raw)
In-Reply-To: <cf3e63c8-836c-1112-c7da-ae375ac43b65@oracle.com>
On Mon, Oct 26, 2020 at 05:23:43PM -0700, Mike Kravetz wrote:
> On 10/9/20 9:23 AM, Hui Su wrote:
> > in old code, it shows like:
> > Node 0 ShmemHugePages: 0 kB
> > Node 0 ShmemPmdMapped: 0 kB
> > Node 0 FileHugePages: 0 kB
> > Node 0 FilePmdMapped: 0 kB
> > Node 0 HugePages_Total: 0
> > Node 0 HugePages_Free: 0
> > Node 0 HugePages_Surp: 0
> >
> > which is not align. So we align it.
> >
> > Signed-off-by: Hui Su <sh_def@163.com>
>
> Apologies for the late reply.
>
> I assume you you just want to make the output look better. Correct?
>
> To be honest, I am not sure about the policy for changing the output
> of sysfs files. My preference would be to not change the output. Why?
> When the output is changed there is always the possibility that someone
> may have written code that depends on the current format. It looks like
> the output has been misaligned since the day the code was first written.
>
> This code was recently changed to use sysfs_emit_at() instead of
> sprintf(). At that time Greg noted that this also violates the sysfs
> rule of one value per file. So, it appears there may be a bigger issue
> than alignment.
>
> Greg,
> Is it OK to break up these sysfs files to be one value per file if they
> contained multiple values from day 1 of their existence? I would prefer
> not to touch them in case some is depending on current format.
You should create multiple files, with a different name, and then remove
this file. Any tool that uses sysfs should be able to handle a file
going away, don't change the format of the data in the file, otherwise
there's no way for anyone to know what is happening.
thanks,
greg k-h
prev parent reply other threads:[~2020-10-27 6:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-09 16:23 [PATCH] mm/hugetable.c: align some prints Hui Su
2020-10-27 0:23 ` Mike Kravetz
2020-10-27 6:14 ` Greg KH [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=20201027061438.GA206502@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=rafael@kernel.org \
--cc=sh_def@163.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 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.