All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	david@redhat.com, akpm@linux-foundation.org
Subject: Re: [PATCH v2 4/4] mm/hugetl.c: warn out if expected count of huge pages adjustment is not achieved
Date: Tue, 11 Aug 2020 10:11:52 +0800	[thread overview]
Message-ID: <20200811021152.GW14854@MiWiFi-R3L-srv> (raw)
In-Reply-To: <b94f4dc1-5c53-68ca-2023-0aa4de4df8b7@oracle.com>

Hi Mike,

On 07/23/20 at 11:21am, Mike Kravetz wrote:
> On 7/23/20 2:11 AM, Baoquan He wrote:
...
> >> But is kernel expected to warn for all such situations where the user
> >> requested resources could not be allocated completely ? Otherwise, it
> >> does not make sense to add an warning for just one such situation.
> > 
> > It's not for just one such situation, we have already had one to warn
> > out in mm/hugetlb.c, please check hugetlb_hstate_alloc_pages().
> 
> Those are a little different in that they are warnings based on kernel
> command line parameters.
> 
> > As Mike said, in one time of persistent huge page number setting,
> > comparing the old value with the new vlaue is good enough for customer
> > to get the information. However, if customer want to detect and analyze
> > previous setting failure, logging message will be helpful. So I think
> > logging the failure or partial success makes sense.
> 
> I can understand the argument against adding a new warning for this.
> You could even argue that this condition has existed since the time
> hugetlb was added to the kernel which was long ago.  And, nobody has
> complained enough to add a warning.  I have even heard of a sysadmin
> practice of asking for a ridiculously large amount of hugetlb pages
> just so that the kernel will allocate as many as possible.  They do
> not 'expect' to get the ridiculous amount they asked for.  In such
> cases, this will be a new warning in their log.
> 
> As mentioned in a previous e-mail, when one sets nr_hugepages by writing
> to the sysfs or proc file, one needs to read the file to determine if the
> number of requested pages were actually allocated.  Anyone who does not
> do this is just asking for trouble.  Yet, I imagine that it may happen.
> 
> To be honest, I do not see this log message as something that would be
> helpful to end users.  Rather, I could see this as being useful to support
> people.  Support always asks for system logs and this could point out a
> possible issue with hugetlb usage.
> 
> I do not feel strongly one way or another about adding the warning.  Since
> it is fairly trivial and could help diagnose issues I am in favor of adding
> it.  If people feel strongly that it should not be added, I am open to
> those arguments.

Ping!

It's been a while, seems no objection to log the message. Do you
consider accepting this patch or offering an Ack?

Thanks
Baoquan



  parent reply	other threads:[~2020-08-11  2:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-23  3:22 [PATCH v2 0/4] mm/hugetlb: Small cleanup and improvement Baoquan He
2020-07-23  3:22 ` [PATCH v2 1/4] mm/hugetlb.c: make is_hugetlb_entry_hwpoisoned return bool Baoquan He
2020-07-23  4:46   ` Anshuman Khandual
2020-07-23  3:22 ` [PATCH v2 2/4] mm/hugetlb.c: Remove the unnecessary non_swap_entry() Baoquan He
2020-07-23  5:06   ` Anshuman Khandual
2020-07-23  6:14     ` Baoquan He
2020-07-23  8:52       ` Anshuman Khandual
2020-07-23 10:46   ` [PATCH v3 " Baoquan He
2020-07-23  3:22 ` [PATCH v2 3/4] doc/vm: fix typo in the hugetlb admin documentation Baoquan He
2020-07-23  5:17   ` Anshuman Khandual
2020-07-23  5:57     ` Baoquan He
2020-07-23  3:22 ` [PATCH v2 4/4] mm/hugetl.c: warn out if expected count of huge pages adjustment is not achieved Baoquan He
2020-07-23  6:16   ` Anshuman Khandual
2020-07-23  9:11     ` Baoquan He
2020-07-23 18:21       ` Mike Kravetz
2020-07-24 14:59         ` Baoquan He
2020-08-11  2:11         ` Baoquan He [this message]
2020-08-11  3:35           ` Mike Kravetz
2020-08-11  7:24             ` Michal Hocko
2020-08-11 23:11               ` Mike Kravetz
2020-08-24 21:57 ` [PATCH v2 0/4] mm/hugetlb: Small cleanup and improvement Mike Kravetz

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=20200811021152.GW14854@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=david@redhat.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 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.