From: Mike Kravetz <mike.kravetz@oracle.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Baoquan He <bhe@redhat.com>,
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 16:11:36 -0700 [thread overview]
Message-ID: <89039447-f2f6-1c5e-f8c0-10314a002069@oracle.com> (raw)
In-Reply-To: <20200811072212.GD4793@dhcp22.suse.cz>
On 8/11/20 12:24 AM, Michal Hocko wrote:
>
> My opinion is that the warning is too late to add at this stage. It
> would have been much better if the user interface has provided a
> reasonable feedback on how much the request was sucessful. But this
> is not the case (except for few error cases) and we have to live with
> the interface where the caller has to read the value after writing to
> it. Lame but a reality.
>
> I have heard about people making an opportunistic attempt to grab as
> many hugetlb pages as possible and they do expect the failure and scale
> the request size down. I do not think those would appreciate warnings.
>
> That being said I would rather keep the existing behavior even though it
> is suboptimal. It is just trivial to add the check in the userspace
> without risking complains by other users. Besides the warning is not
> really telling us much more than a subsequent read anyway. You are not
> going to learn why the allocation has failed because that one is done
> (intentionaly) as __GFP_NOWARN.
>
Thanks Michal.
As previously stated, I do not have a strong opinion about this. Because of
this, let's just leave things as they are and not add the message.
It is pretty clear that a user needs to read the value after writing to
determine if all pages were allocated. The log message would add little
benefit to the end user.
--
Mike Kravetz
next prev parent reply other threads:[~2020-08-11 23:11 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
2020-08-11 3:35 ` Mike Kravetz
2020-08-11 7:24 ` Michal Hocko
2020-08-11 23:11 ` Mike Kravetz [this message]
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=89039447-f2f6-1c5e-f8c0-10314a002069@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=bhe@redhat.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.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