linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Oscar Salvador <osalvador@suse.de>,
	Mel Gorman <mgorman@techsingularity.net>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Pavel Tatashin <pavel.tatashin@microsoft.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages()
Date: Fri, 4 Oct 2019 17:14:11 +0530	[thread overview]
Message-ID: <91128b73-9a47-100b-d3de-e83f0b941e9f@arm.com> (raw)
In-Reply-To: <20191004105824.GD9578@dhcp22.suse.cz>



On 10/04/2019 04:28 PM, Michal Hocko wrote:
> On Thu 03-10-19 13:40:57, Anshuman Khandual wrote:
>> Having unmovable pages on a given pageblock should be reported correctly
>> when required with REPORT_FAILURE flag. But there can be a scenario where a
>> reserved page in the page block will get reported as a generic "unmovable"
>> reason code. Instead this should be changed to a more appropriate reason
>> code like "Reserved page".
> 
> Others have already pointed out this is just redundant but I will have a

Sure.

> more generic comment on the changelog. There is essentially no
> information why the current state is bad/unhelpful and why the chnage is

The current state is not necessarily bad or unhelpful. I just though that it
could be improved upon. Some how calling out explicitly only the CMA page
failure case just felt adhoc, where as there are other reasons like HugeTLB
immovability which might depend on other factors apart from just page flags
(though I did not propose that originally).

> needed. All you claim is that something is a certain way and then assert
> that it should be done differently. That is not how changelogs should
> look like.
> 

Okay, probably I should have explained more on why "unmovable" is less than
adequate to capture the exact reason for specific failure cases and how
"Reserved Page" instead would been better. But got the point, will improve.


  reply	other threads:[~2019-10-04 11:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-03  8:10 [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages() Anshuman Khandual
2019-10-03  9:05 ` Qian Cai
2019-10-03  9:32   ` Anshuman Khandual
2019-10-03  9:53     ` Anshuman Khandual
2019-10-03 11:19     ` Qian Cai
2019-10-03 11:32       ` Anshuman Khandual
2019-10-03 11:50         ` Qian Cai
2019-10-03 12:02           ` Anshuman Khandual
2019-10-03 12:14             ` Qian Cai
2019-10-04  8:25               ` David Hildenbrand
2020-01-14  8:19                 ` Anshuman Khandual
2020-01-14  8:30                   ` David Hildenbrand
2020-01-14  9:10                   ` Michal Hocko
2020-01-14 10:23                     ` Vlastimil Babka
2020-01-14 11:03                       ` Anshuman Khandual
2020-01-14 11:32                       ` Michal Hocko
2020-01-14 12:04                         ` [PATCH] mm, debug: always print flags in dump_page() Vlastimil Babka
2020-01-14 13:35                           ` Michal Hocko
2020-01-14 18:22                         ` [PATCH] mm/page_alloc: Add a reason for reserved pages in has_unmovable_pages() Ralph Campbell
2019-10-04 10:58 ` Michal Hocko
2019-10-04 11:44   ` Anshuman Khandual [this message]
2019-10-04 12:56     ` Qian Cai
2019-10-04 13:07       ` Michal Hocko
2019-10-04 13:30         ` Qian Cai
2019-10-04 13:38           ` Michal Hocko
2019-10-04 13:56             ` Qian Cai
2019-10-04 14:41               ` Michal Hocko
2019-10-05 21:22                 ` Andrew Morton
2019-10-05 22:38                   ` Qian Cai

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=91128b73-9a47-100b-d3de-e83f0b941e9f@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=pavel.tatashin@microsoft.com \
    --cc=rppt@linux.ibm.com \
    --cc=vbabka@suse.cz \
    /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).