linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Chuyi Zhou <zhouchuyi@bytedance.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org
Subject: Re: [PATCH v3] mm/compaction: fix set skip in fast_find_migrateblock
Date: Tue, 19 Jul 2022 09:28:54 +0100	[thread overview]
Message-ID: <20220719082854.GB3563@techsingularity.net> (raw)
In-Reply-To: <3529e159-8c22-5d67-5e5d-c912784df9a0@bytedance.com>

On Fri, Jul 15, 2022 at 11:26:01PM +0800, Chuyi Zhou wrote:
> 
> 
> ??? 2022/7/14 ??????7:50, Mel Gorman ??????:
> > On Wed, Jul 13, 2022 at 08:28:14AM -0700, Andrew Morton wrote:
> > > (cc Mel)
> > > 
> > > On Wed, 13 Jul 2022 14:20:09 +0800 Chuyi Zhou <zhouchuyi@bytedance.com> wrote:
> > > 
> > > > From: zhouchuyi <zhouchuyi@bytedance.com>
> > > > 
> > > > When we successfully find a pageblock in fast_find_migrateblock(),
> > > > the block will be set skip-flag through set_pageblock_skip(). However,
> > > > when entering isolate_migratepages_block(), the whole pageblock will
> > > > be skipped due to the branch
> > > > 'if (!valid_page && IS_ALIGNED(low_pfn, pageblock_nr_pages))'.
> > > > Eventually we will goto isolate_abort and isolate nothing. That cause
> > > > fast_find_migrateblock useless.
> > > > 
> > 
> > It's not very clear *why* this failed from the changelog because
> > superficially !valid_page will be true for the first pageblock and there
> > is a reasonable expectation it will be aligned. Is the following accurate
> > based on your analysis?
> > 
> > 	However, when entering isolate_migratepages_block(), the first
> > 	pageblock will be skipped in the branch 'if (!valid_page &&
> > 	IS_ALIGNED(low_pfn, pageblock_nr_pages))' as isolation_suitable
> > 	returns true due to the skip bit set by fast_find_migrateblock().
> > 
> > If so, please update the changelog as a reviewer handling backports may
> > wonder what exactly is wrong with that branch.
> > 
> Hi Mel, thanks for your review.
> 
> If fast scanning failed, the return block may not be aligned, because we get
> pfn from *free_pfn*. When fast-find success, the return value *pfn* is get
> from pageblock_start_pfn, and it will be passed to
> isolate_migratepages_block as low_pfn. I think normally the value get from
> pageblock_start_pfn should be aligned with pageblock_nr_pages. I have used
> printk test it. Maby I miss something important?
>     pfn = pageblock_start_pfn(free_pfn);
>     ...
>     found_block = true;
>     set_pageblock_skip(freepage);
>     break;

The return block indeed may not be aligned. It could simply be a
restart. The changelog could still do with a little clarification but
your patch is still fine.

> > Second, what guarantees a block returned by fast_find that is not
> > aligned gets marked skipped after it is scanned? The set_pageblock_skip
> > is only called when there is a valid page and it may not be set if
> > !IS_ALIGNED(low_pfn). Is something like this untested hunk also necessary?
> > 
> You are right, we do need some machenism to ensure mark skipped after
> scanned a !IS_ALIGNED block from fast_find. However, I think the following
> code may not working. Because *skip_updated* has been reset:
>     if (!skip_updated) {
>         skip_updated = true;
>         if (test_and_set_skip(cc, page, low_pfn))
>             goto isolate_abort;
>     }
> Why not ignore skip_updated after scanned a block, just like this:
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 962d05d1e187..1c388c45f127 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1180,7 +1180,7 @@ isolate_migratepages_block(struct compact_control *cc,
> unsigned long low_pfn,
>          * rescanned twice in a row.
>          */
>         if (low_pfn == end_pfn && (!nr_isolated || cc->rescan)) {
> -               if (valid_page && !skip_updated)
> +               if (valid_page)
>                         set_pageblock_skip(valid_page);
>                 update_cached_migrate(cc, low_pfn);
>         }
> 

Because valid_page still needs to be set but ensuring valid_page is set
is sufficient.

The pageblock will be marked for skip on the first locking of a lruvec

                        /* Try get exclusive access under lock */
                        if (!skip_updated) {
                                skip_updated = true;
                                if (test_and_set_skip(cc, page, low_pfn))
                                        goto isolate_abort;
                        }

That will happen regardless of alignment. The intent here was to avoid
multiple scanners trying to isolate the same pageblock. The second
check for update happens at the end of the block

        if (low_pfn == end_pfn && (!nr_isolated || cc->rescan)) {
                if (valid_page && !skip_updated)
                        set_pageblock_skip(valid_page);
                update_cached_migrate(cc, low_pfn);
        }

And it's the second one that requires a valid_page. If valid_page is
available then the pageblock will get marked skip in most cases that
matter. If anything, it can get set prematurely due to "Try get
exclusive access" if the pageblock is not fully scanned but checking if
pageblock should be *cleared* if there was a partial scan would be a
different patch and not even clear that it worth the complexity.

-- 
Mel Gorman
SUSE Labs


  reply	other threads:[~2022-07-19  8:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13  6:20 Chuyi Zhou
2022-07-13 15:28 ` Andrew Morton
2022-07-14 11:50   ` Mel Gorman
2022-07-15 15:26     ` Chuyi Zhou
2022-07-19  8:28       ` Mel Gorman [this message]
2022-08-15  1:24         ` Andrew Morton
     [not found]           ` <70a434b2-7f1c-7fad-a7b7-cb038a13fd2c@bytedance.com>
2022-08-15  3:22             ` Chuyi Zhou
     [not found]         ` <7d2bbb38-a96c-8212-8f89-915cd2c8668f@bytedance.com>
2022-08-17  3:10           ` Chuyi Zhou
2023-01-09 19:43         ` Vlastimil Babka
2023-01-11 14:21           ` Mel Gorman
2023-01-13 17:13             ` Vlastimil Babka

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=20220719082854.GB3563@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=zhouchuyi@bytedance.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