From: Michal Hocko <mhocko@suse.com>
To: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Muchun Song <songmuchun@bytedance.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/5] mm,page_alloc: Bail out earlier on -ENOMEM in alloc_contig_migrate_range
Date: Wed, 17 Mar 2021 15:49:54 +0100 [thread overview]
Message-ID: <YFIXElOEfMuVEOZh@dhcp22.suse.cz> (raw)
In-Reply-To: <89830f41-b3f2-a158-a173-8c14101edcaa@redhat.com>
On Wed 17-03-21 15:42:43, David Hildenbrand wrote:
> On 17.03.21 15:05, Michal Hocko wrote:
> > On Wed 17-03-21 12:12:47, Oscar Salvador wrote:
> > > Currently, __alloc_contig_migrate_range can generate -EINTR, -ENOMEM or -EBUSY,
> > > and report them down the chain.
> > > The problem is that when migrate_pages() reports -ENOMEM, we keep going till we
> > > exhaust all the try-attempts (5 at the moment) instead of bailing out.
> > >
> > > migrate_pages() bails out right away on -ENOMEM because it is considered a fatal
> > > error. Do the same here instead of keep going and retrying.
> >
> > I suspect this is not really a real life problem, right? The allocation
> > would be more costly in the end but this is to be expected under a heavy
> > memory pressure.
> >
> > That being said, bailing out early makes sense to me. But now that
> > you've made me look into the migrate_pages excellent error state reporting
> > I suspect we have a bug here. Note the
> > "Returns the number of pages that were not migrated, or an error code."
> >
> > but I do not see putback_movable_pages for ret > 0 so it seems we might
> > leak some pages.
>
> At least in __alloc_contig_migrate_range() we seem to always leave the loop
> with ret <= 0 and do a putback_movable_pages() with ret < 0.
>
> Which code are you referring to?
OK, my bad. I have managed to confuse myself around the retry bailout
which indeed overrides the return value. So there is no bug. Sorry about
the noise but I still believe making migrate_pages less tricky with
error handling would be an improvement.
Thanks!
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2021-03-17 15:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-17 11:12 [PATCH v5 0/5] Make alloc_contig_range handle Hugetlb pages Oscar Salvador
2021-03-17 11:12 ` [PATCH v5 1/5] mm,page_alloc: Bail out earlier on -ENOMEM in alloc_contig_migrate_range Oscar Salvador
2021-03-17 14:05 ` Michal Hocko
2021-03-17 14:42 ` David Hildenbrand
2021-03-17 14:49 ` Michal Hocko [this message]
2021-03-18 11:04 ` Oscar Salvador
2021-03-18 11:37 ` Michal Hocko
2021-03-17 11:12 ` [PATCH v5 2/5] mm,compaction: Let isolate_migratepages_{range,block} return error codes Oscar Salvador
2021-03-17 14:12 ` Michal Hocko
2021-03-17 14:38 ` Oscar Salvador
2021-03-17 14:59 ` Michal Hocko
2021-03-18 9:50 ` Vlastimil Babka
2021-03-18 10:22 ` Michal Hocko
2021-03-18 11:10 ` Vlastimil Babka
2021-03-18 11:36 ` Michal Hocko
2021-03-19 9:57 ` Oscar Salvador
2021-03-19 10:14 ` Vlastimil Babka
2021-03-19 10:26 ` Oscar Salvador
2021-03-17 11:12 ` [PATCH v5 3/5] mm: Make alloc_contig_range handle free hugetlb pages Oscar Salvador
2021-03-17 14:22 ` Michal Hocko
2021-03-17 11:12 ` [PATCH v5 4/5] mm: Make alloc_contig_range handle in-use " Oscar Salvador
2021-03-17 14:26 ` Michal Hocko
2021-03-18 8:54 ` Oscar Salvador
2021-03-18 9:29 ` Michal Hocko
2021-03-18 9:59 ` Oscar Salvador
2021-03-18 10:12 ` Michal Hocko
2021-03-17 11:12 ` [PATCH v5 5/5] mm,page_alloc: Drop unnecessary checks from pfn_range_valid_contig Oscar Salvador
2021-03-17 11:15 ` David Hildenbrand
2021-03-17 14:31 ` Michal Hocko
2021-03-17 14:36 ` David Hildenbrand
2021-03-17 15:03 ` Michal Hocko
2021-03-18 8:44 ` Oscar Salvador
2021-03-18 8:55 ` Michal Hocko
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=YFIXElOEfMuVEOZh@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=osalvador@suse.de \
--cc=songmuchun@bytedance.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 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.