linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@suse.com>, Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	joaodias@google.com
Subject: Re: [PATCH] mm: be more verbose for alloc_contig_range faliures
Date: Mon, 8 Mar 2021 14:22:12 +0100	[thread overview]
Message-ID: <c1461e51-7ad0-7fb5-9dc2-7f7c5cdf128f@redhat.com> (raw)
In-Reply-To: <YEYdR8azcawau9Rl@dhcp22.suse.cz>

On 08.03.21 13:49, Michal Hocko wrote:
> On Thu 04-03-21 10:22:51, Minchan Kim wrote:
> [...]
>> How about this?
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 238d0fc232aa..489e557b9390 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -8481,7 +8481,8 @@ static inline void dump_migrate_failure_pages(struct list_head *page_list)
>>
>>   /* [start, end) must belong to a single zone. */
>>   static int __alloc_contig_migrate_range(struct compact_control *cc,
>> -                                       unsigned long start, unsigned long end)
>> +                                       unsigned long start, unsigned long end,
>> +                                       bool nofail)
> 
> This sounds like a very bad idea to me. Your nofail definition might
> differ from what we actually define as __GFP_NOFAIL but I do not think
> this interface should ever promise anything that strong.
> Sure movable, cma regions should effectively never fail but there will
> never be any _guarantee_ for that.

While there are no guarantees, we want to make such allocations as 
likely as possible to succeed. Not succeeding should be the corner case 
and is worth investigating.

> 
> Earlier in the discussion I have suggested dynamic debugging facility.
> Documentation/admin-guide/dynamic-debug-howto.rst. Have you tried to
> look into that direction?

Did you see the previous mail this is based on:

https://lkml.kernel.org/r/YEEUq8ZRn4WyYWVx@google.com

I agree that "nofail" is misleading. Rather something like 
"dump_on_failure", just a better name :)

-- 
Thanks,

David / dhildenb


  reply	other threads:[~2021-03-08 13:23 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 16:36 [PATCH] mm: be more verbose for alloc_contig_range faliures Minchan Kim
2021-02-17 16:51 ` David Hildenbrand
2021-02-17 17:26   ` Minchan Kim
2021-02-17 17:34     ` David Hildenbrand
2021-02-17 17:45       ` Minchan Kim
2021-02-18  8:56 ` Michal Hocko
2021-02-18  9:02   ` David Hildenbrand
2021-02-18  9:35     ` Michal Hocko
2021-02-18  9:43       ` David Hildenbrand
2021-02-18  9:59         ` Michal Hocko
2021-02-18 16:19         ` Minchan Kim
2021-02-18 16:26           ` David Hildenbrand
2021-02-18 16:47             ` Minchan Kim
2021-02-18 16:53               ` David Hildenbrand
2021-02-19  9:28           ` Michal Hocko
2021-02-19  9:30             ` David Hildenbrand
2021-02-19 10:02               ` Michal Hocko
2021-02-19 10:34                 ` David Hildenbrand
2021-03-02 17:23             ` Minchan Kim
2021-03-04 16:01               ` Minchan Kim
2021-03-04 16:10                 ` David Hildenbrand
2021-03-04 16:23                   ` Minchan Kim
2021-03-04 16:28                     ` David Hildenbrand
2021-03-04 17:11                       ` Minchan Kim
2021-03-04 17:23                         ` David Hildenbrand
2021-03-04 18:11                           ` Minchan Kim
2021-03-04 18:22                             ` Minchan Kim
2021-03-08 12:49                               ` Michal Hocko
2021-03-08 13:22                                 ` David Hildenbrand [this message]
2021-03-08 14:11                                   ` Michal Hocko
2021-03-08 14:13                                     ` David Hildenbrand
2021-03-08 15:42                                       ` Michal Hocko
2021-03-08 15:58                                         ` Minchan Kim
2021-03-08 16:21                                           ` Michal Hocko
2021-03-08 17:01                                             ` Minchan Kim
2021-03-08 20:27                                           ` Minchan Kim
2021-02-18 16:10   ` Minchan Kim

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=c1461e51-7ad0-7fb5-9dc2-7f7c5cdf128f@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=joaodias@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    /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).