linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	David Hildenbrand <david@redhat.com>,
	Muchun Song <songmuchun@bytedance.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/5] mm,compaction: Let isolate_migratepages_{range,block} return error codes
Date: Wed, 17 Mar 2021 15:59:34 +0100	[thread overview]
Message-ID: <YFIZVvQllaZHDgzW@dhcp22.suse.cz> (raw)
In-Reply-To: <20210317143827.GA20965@linux>

On Wed 17-03-21 15:38:35, Oscar Salvador wrote:
> On Wed, Mar 17, 2021 at 03:12:29PM +0100, Michal Hocko wrote:
> > > Since isolate_migratepages_block will stop returning the next pfn to be
> > > scanned, we reuse the cc->migrate_pfn field to keep track of that.
> > 
> > This looks hakish and I cannot really tell that users of cc->migrate_pfn
> > work as intended.
> 
> When discussing this with Vlastimil, I came up with the idea of adding a new
> field in compact_control struct, e.g: next_pfn_scan to keep track of the next
> pfn to be scanned.
> 
> But Vlastimil made me realize that since cc->migrate_pfn points to that aleady,
> so we do not need any extra field.

This deserves a big fat comment.

> > > @@ -810,6 +811,8 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
> > >  	unsigned long next_skip_pfn = 0;
> > >  	bool skip_updated = false;
> > >  
> > > +	cc->migrate_pfn = low_pfn;
> > > +
> > >  	/*
> > >  	 * Ensure that there are not too many pages isolated from the LRU
> > >  	 * list by either parallel reclaimers or compaction. If there are,
> > > @@ -818,16 +821,16 @@ isolate_migratepages_block(struct compact_control *cc, unsigned long low_pfn,
> > >  	while (unlikely(too_many_isolated(pgdat))) {
> > >  		/* stop isolation if there are still pages not migrated */
> > >  		if (cc->nr_migratepages)
> > > -			return 0;
> > > +			return -EINTR;
> > >  
> > >  		/* async migration should just abort */
> > >  		if (cc->mode == MIGRATE_ASYNC)
> > > -			return 0;
> > > +			return -EINTR;
> > 
> > EINTR for anything other than signal based bail out is really confusing.
> 
> When coding that, I thought about using -1 for the first two checks, and keep
> -EINTR for the signal check, but isolate_migratepages_block only has two users:

No, do not mix error reporting with different semantic. Either make it
errno or return -1 for all failures if you do not care which error that
is. You do care and hence this patch so make that errno and above two
should simply EAGAIN as this is a congestion situation.

> - isolate_migratepages: Does not care about the return code other than pfn != 0,
>   and it does not pass the error down the chain.
> - isolate_migratepages_range: The error is passed down the chain, and !pfn is being
>   treated as -EINTR:
> 
> static int __alloc_contig_migrate_range(struct compact_control *cc,
> 					unsigned long start, unsigned long end)
>  {
>   ...
>   ...
>   pfn = isolate_migratepages_range(cc, pfn, end);
>   if (!pfn) {
>           ret = -EINTR;
>           break;
>   }
>   ...
>  }
> 
> That is why I decided to stick with -EINTR.

I suspect this is only because there was not really a better way to tell
the failure so it went with EINTR which makes alloc_contig_range bail
out. The high level handling there is quite dubious as EAGAIN is already
possible from the page migration path and that shouldn't be a fatal
failure.
-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2021-03-17 15:13 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
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 [this message]
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=YFIZVvQllaZHDgzW@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox