linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock()
@ 2021-01-28 13:04 Wonhyuk Yang
  2021-01-28 13:25 ` Mel Gorman
  2021-01-28 14:34 ` Vlastimil Babka
  0 siblings, 2 replies; 9+ messages in thread
From: Wonhyuk Yang @ 2021-01-28 13:04 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Mel Gorman, Vlastimil Babka, linux-mm, Wonhyuk Yang

In the fast_find_migrateblock(), It iterate freelist to find
proper pageblock. But there are some misbehaviors.

 First, if the page we found is equal to cc->migrate_pfn, it
is considered that we didn't found suitable pageblock. Second,
if the loop was terminated because order is less than
PAGE_ALLOC_COSTLY_ORDER, it could be considered that we found
suitable one. Third, if the skip bit is set on the page block
and go continue, it doesn't check the nr_scanned. Fourth, if
the page block's skip bit is set, it check that page block is
the last of list. But it is unnecessary.

Fixes: 70b44595eafe9 ("mm, compaction: use free lists to quickly locate
a migration source")

Signed-off-by: Wonhyuk Yang <vvghjk1234@gmail.com>
---
Changes in v2:
  - Follow Vlastimil's suggestions, using bool varable.
  - Fix new misbehavior and remove unecessary .

v1: https://lore.kernel.org/linux-mm/20210123154320.24278-1-vvghjk1234@gmail.com
---
 mm/compaction.c | 27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index e5acb9714436..8e5cd9d20435 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1701,6 +1701,7 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
 	unsigned long pfn = cc->migrate_pfn;
 	unsigned long high_pfn;
 	int order;
+	bool found_block = false;
 
 	/* Skip hints are relied on to avoid repeats on the fast search */
 	if (cc->ignore_skip_hint)
@@ -1743,7 +1744,7 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
 	high_pfn = pageblock_start_pfn(cc->migrate_pfn + distance);
 
 	for (order = cc->order - 1;
-	     order >= PAGE_ALLOC_COSTLY_ORDER && pfn == cc->migrate_pfn && nr_scanned < limit;
+	     order >= PAGE_ALLOC_COSTLY_ORDER && !found_block && nr_scanned < limit;
 	     order--) {
 		struct free_area *area = &cc->zone->free_area[order];
 		struct list_head *freelist;
@@ -1758,7 +1759,11 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
 		list_for_each_entry(freepage, freelist, lru) {
 			unsigned long free_pfn;
 
-			nr_scanned++;
+			if (nr_scanned++ >= limit) {
+				move_freelist_tail(freelist, freepage);
+				break;
+			}
+
 			free_pfn = page_to_pfn(freepage);
 			if (free_pfn < high_pfn) {
 				/*
@@ -1767,12 +1772,8 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
 				 * the list assumes an entry is deleted, not
 				 * reordered.
 				 */
-				if (get_pageblock_skip(freepage)) {
-					if (list_is_last(freelist, &freepage->lru))
-						break;
-
+				if (get_pageblock_skip(freepage))
 					continue;
-				}
 
 				/* Reorder to so a future search skips recent pages */
 				move_freelist_tail(freelist, freepage);
@@ -1780,15 +1781,10 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
 				update_fast_start_pfn(cc, free_pfn);
 				pfn = pageblock_start_pfn(free_pfn);
 				cc->fast_search_fail = 0;
+				found_block = true;
 				set_pageblock_skip(freepage);
 				break;
 			}
-
-			if (nr_scanned >= limit) {
-				cc->fast_search_fail++;
-				move_freelist_tail(freelist, freepage);
-				break;
-			}
 		}
 		spin_unlock_irqrestore(&cc->zone->lock, flags);
 	}
@@ -1799,9 +1795,10 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
 	 * If fast scanning failed then use a cached entry for a page block
 	 * that had free pages as the basis for starting a linear scan.
 	 */
-	if (pfn == cc->migrate_pfn)
+	if (!found_block) {
+		cc->fast_search_fail++;
 		pfn = reinit_migrate_pfn(cc);
-
+	}
 	return pfn;
 }
 
-- 
2.25.1



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock()
  2021-01-28 13:04 [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock() Wonhyuk Yang
@ 2021-01-28 13:25 ` Mel Gorman
  2021-01-28 13:50   ` Wonhyuk Yang
  2021-01-28 14:34 ` Vlastimil Babka
  1 sibling, 1 reply; 9+ messages in thread
From: Mel Gorman @ 2021-01-28 13:25 UTC (permalink / raw)
  To: Wonhyuk Yang; +Cc: Andrew Morton, Vlastimil Babka, linux-mm

On Thu, Jan 28, 2021 at 10:04:11PM +0900, Wonhyuk Yang wrote:
> In the fast_find_migrateblock(), It iterate freelist to find
> proper pageblock. But there are some misbehaviors.
> 
>  First, if the page we found is equal to cc->migrate_pfn, it
> is considered that we didn't found suitable pageblock. Second,
> if the loop was terminated because order is less than
> PAGE_ALLOC_COSTLY_ORDER, it could be considered that we found
> suitable one. Third, if the skip bit is set on the page block
> and go continue, it doesn't check the nr_scanned. Fourth, if
> the page block's skip bit is set, it check that page block is
> the last of list. But it is unnecessary.
> 
> Fixes: 70b44595eafe9 ("mm, compaction: use free lists to quickly locate
> a migration source")
> 
> Signed-off-by: Wonhyuk Yang <vvghjk1234@gmail.com>
> ---
> Changes in v2:
>   - Follow Vlastimil's suggestions, using bool varable.
>   - Fix new misbehavior and remove unecessary .
> 
> v1: https://lore.kernel.org/linux-mm/20210123154320.24278-1-vvghjk1234@gmail.com
> ---
>  mm/compaction.c | 27 ++++++++++++---------------
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index e5acb9714436..8e5cd9d20435 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1701,6 +1701,7 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
>  	unsigned long pfn = cc->migrate_pfn;
>  	unsigned long high_pfn;
>  	int order;
> +	bool found_block = false;
>  
>  	/* Skip hints are relied on to avoid repeats on the fast search */
>  	if (cc->ignore_skip_hint)
> @@ -1743,7 +1744,7 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
>  	high_pfn = pageblock_start_pfn(cc->migrate_pfn + distance);
>  
>  	for (order = cc->order - 1;
> -	     order >= PAGE_ALLOC_COSTLY_ORDER && pfn == cc->migrate_pfn && nr_scanned < limit;
> +	     order >= PAGE_ALLOC_COSTLY_ORDER && !found_block && nr_scanned < limit;
>  	     order--) {
>  		struct free_area *area = &cc->zone->free_area[order];
>  		struct list_head *freelist;
> @@ -1758,7 +1759,11 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
>  		list_for_each_entry(freepage, freelist, lru) {
>  			unsigned long free_pfn;
>  
> -			nr_scanned++;
> +			if (nr_scanned++ >= limit) {
> +				move_freelist_tail(freelist, freepage);
> +				break;
> +			}
> +
>  			free_pfn = page_to_pfn(freepage);
>  			if (free_pfn < high_pfn) {
>  				/*

As nr_scanned is post-incremented, this will still consider if the page
should be used when the limit is reached. ++nr_scanned?

-- 
Mel Gorman
SUSE Labs


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock()
  2021-01-28 13:25 ` Mel Gorman
@ 2021-01-28 13:50   ` Wonhyuk Yang
  2021-01-28 14:01     ` Vlastimil Babka
  0 siblings, 1 reply; 9+ messages in thread
From: Wonhyuk Yang @ 2021-01-28 13:50 UTC (permalink / raw)
  To: Mel Gorman; +Cc: Andrew Morton, Vlastimil Babka, linux-mm

On Thu, Jan 28, 2021 at 10:25 PM Mel Gorman <mgorman@techsingularity.net> wrote:
>
> As nr_scanned is post-incremented, this will still consider if the page
> should be used when the limit is reached. ++nr_scanned?

Hi,

Let's consider that limit is 4, nr_scanned is 0 and loop until reach the limit.
1) pre-increment: it will search three times.(0,1,2)
2) post-increment: it will search four times. (0,1,2,3)

So you mean that searching three times is correct?


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock()
  2021-01-28 13:50   ` Wonhyuk Yang
@ 2021-01-28 14:01     ` Vlastimil Babka
  2021-01-28 14:22       ` Mel Gorman
  0 siblings, 1 reply; 9+ messages in thread
From: Vlastimil Babka @ 2021-01-28 14:01 UTC (permalink / raw)
  To: Wonhyuk Yang, Mel Gorman; +Cc: Andrew Morton, linux-mm

On 1/28/21 2:50 PM, Wonhyuk Yang wrote:
> On Thu, Jan 28, 2021 at 10:25 PM Mel Gorman <mgorman@techsingularity.net> wrote:
>>
>> As nr_scanned is post-incremented, this will still consider if the page
>> should be used when the limit is reached. ++nr_scanned?
> 
> Hi,
> 
> Let's consider that limit is 4, nr_scanned is 0 and loop until reach the limit.
> 1) pre-increment: it will search three times.(0,1,2)
> 2) post-increment: it will search four times. (0,1,2,3)
> 
> So you mean that searching three times is correct?

1) will match the outer loop's "nr_scanned < limit;" condition. It doesn't
matter that much in practice, but for consistency sake, it should be 1)


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock()
  2021-01-28 14:01     ` Vlastimil Babka
@ 2021-01-28 14:22       ` Mel Gorman
  2021-01-28 14:31         ` Wonhyuk Yang
  0 siblings, 1 reply; 9+ messages in thread
From: Mel Gorman @ 2021-01-28 14:22 UTC (permalink / raw)
  To: Vlastimil Babka; +Cc: Wonhyuk Yang, Andrew Morton, linux-mm

On Thu, Jan 28, 2021 at 03:01:27PM +0100, Vlastimil Babka wrote:
> On 1/28/21 2:50 PM, Wonhyuk Yang wrote:
> > On Thu, Jan 28, 2021 at 10:25 PM Mel Gorman <mgorman@techsingularity.net> wrote:
> >>
> >> As nr_scanned is post-incremented, this will still consider if the page
> >> should be used when the limit is reached. ++nr_scanned?
> > 
> > Hi,
> > 
> > Let's consider that limit is 4, nr_scanned is 0 and loop until reach the limit.
> > 1) pre-increment: it will search three times.(0,1,2)
> > 2) post-increment: it will search four times. (0,1,2,3)
> > 
> > So you mean that searching three times is correct?
> 
> 1) will match the outer loop's "nr_scanned < limit;" condition. It doesn't
> matter that much in practice, but for consistency sake, it should be 1)

Ok, while I find it a little strange to enter the loop and then break
immediately due to the limit, it's a marginal difference and in general,
the patch makes sense.

-- 
Mel Gorman
SUSE Labs


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock()
  2021-01-28 14:22       ` Mel Gorman
@ 2021-01-28 14:31         ` Wonhyuk Yang
  2021-01-28 14:40           ` Vlastimil Babka
  0 siblings, 1 reply; 9+ messages in thread
From: Wonhyuk Yang @ 2021-01-28 14:31 UTC (permalink / raw)
  To: Mel Gorman; +Cc: Vlastimil Babka, Andrew Morton, linux-mm

On Thu, Jan 28, 2021 at 11:23 PM Mel Gorman <mgorman@techsingularity.net> wrote:
>
> On Thu, Jan 28, 2021 at 03:01:27PM +0100, Vlastimil Babka wrote:
> > On 1/28/21 2:50 PM, Wonhyuk Yang wrote:
> > > On Thu, Jan 28, 2021 at 10:25 PM Mel Gorman <mgorman@techsingularity.net> wrote:
> > >>
> > >> As nr_scanned is post-incremented, this will still consider if the page
> > >> should be used when the limit is reached. ++nr_scanned?
> > >
> > > Hi,
> > >
> > > Let's consider that limit is 4, nr_scanned is 0 and loop until reach the limit.
> > > 1) pre-increment: it will search three times.(0,1,2)
> > > 2) post-increment: it will search four times. (0,1,2,3)
> > >
> > > So you mean that searching three times is correct?
> >
> > 1) will match the outer loop's "nr_scanned < limit;" condition. It doesn't
> > matter that much in practice, but for consistency sake, it should be 1)
>
> Ok, while I find it a little strange to enter the loop and then break
> immediately due to the limit, it's a marginal difference and in general,
> the patch makes sense.
>

Then, should I change post-increment to pre-increment?
If so, should I send a new version? It seems like it's too tiny change...


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock()
  2021-01-28 13:04 [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock() Wonhyuk Yang
  2021-01-28 13:25 ` Mel Gorman
@ 2021-01-28 14:34 ` Vlastimil Babka
  1 sibling, 0 replies; 9+ messages in thread
From: Vlastimil Babka @ 2021-01-28 14:34 UTC (permalink / raw)
  To: Wonhyuk Yang, Andrew Morton; +Cc: Mel Gorman, linux-mm

On 1/28/21 2:04 PM, Wonhyuk Yang wrote:
> In the fast_find_migrateblock(), It iterate freelist to find
> proper pageblock. But there are some misbehaviors.
> 
>  First, if the page we found is equal to cc->migrate_pfn, it
> is considered that we didn't found suitable pageblock. Second,
> if the loop was terminated because order is less than
> PAGE_ALLOC_COSTLY_ORDER, it could be considered that we found
> suitable one. Third, if the skip bit is set on the page block
> and go continue, it doesn't check the nr_scanned. Fourth, if
> the page block's skip bit is set, it check that page block is
> the last of list. But it is unnecessary.
> 
> Fixes: 70b44595eafe9 ("mm, compaction: use free lists to quickly locate
> a migration source")
> 
> Signed-off-by: Wonhyuk Yang <vvghjk1234@gmail.com>

Acked-by: Vlastimil Babka <vbabka@suse.cz>

> ---
> Changes in v2:
>   - Follow Vlastimil's suggestions, using bool varable.
>   - Fix new misbehavior and remove unecessary .
> 
> v1: https://lore.kernel.org/linux-mm/20210123154320.24278-1-vvghjk1234@gmail.com
> ---
>  mm/compaction.c | 27 ++++++++++++---------------
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/mm/compaction.c b/mm/compaction.c
> index e5acb9714436..8e5cd9d20435 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1701,6 +1701,7 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
>  	unsigned long pfn = cc->migrate_pfn;
>  	unsigned long high_pfn;
>  	int order;
> +	bool found_block = false;
>  
>  	/* Skip hints are relied on to avoid repeats on the fast search */
>  	if (cc->ignore_skip_hint)
> @@ -1743,7 +1744,7 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
>  	high_pfn = pageblock_start_pfn(cc->migrate_pfn + distance);
>  
>  	for (order = cc->order - 1;
> -	     order >= PAGE_ALLOC_COSTLY_ORDER && pfn == cc->migrate_pfn && nr_scanned < limit;
> +	     order >= PAGE_ALLOC_COSTLY_ORDER && !found_block && nr_scanned < limit;
>  	     order--) {
>  		struct free_area *area = &cc->zone->free_area[order];
>  		struct list_head *freelist;
> @@ -1758,7 +1759,11 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
>  		list_for_each_entry(freepage, freelist, lru) {
>  			unsigned long free_pfn;
>  
> -			nr_scanned++;
> +			if (nr_scanned++ >= limit) {
> +				move_freelist_tail(freelist, freepage);
> +				break;
> +			}
> +
>  			free_pfn = page_to_pfn(freepage);
>  			if (free_pfn < high_pfn) {
>  				/*
> @@ -1767,12 +1772,8 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
>  				 * the list assumes an entry is deleted, not
>  				 * reordered.
>  				 */
> -				if (get_pageblock_skip(freepage)) {
> -					if (list_is_last(freelist, &freepage->lru))
> -						break;
> -
> +				if (get_pageblock_skip(freepage))
>  					continue;
> -				}
>  
>  				/* Reorder to so a future search skips recent pages */
>  				move_freelist_tail(freelist, freepage);
> @@ -1780,15 +1781,10 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
>  				update_fast_start_pfn(cc, free_pfn);
>  				pfn = pageblock_start_pfn(free_pfn);
>  				cc->fast_search_fail = 0;
> +				found_block = true;
>  				set_pageblock_skip(freepage);
>  				break;
>  			}
> -
> -			if (nr_scanned >= limit) {
> -				cc->fast_search_fail++;
> -				move_freelist_tail(freelist, freepage);
> -				break;
> -			}
>  		}
>  		spin_unlock_irqrestore(&cc->zone->lock, flags);
>  	}
> @@ -1799,9 +1795,10 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
>  	 * If fast scanning failed then use a cached entry for a page block
>  	 * that had free pages as the basis for starting a linear scan.
>  	 */
> -	if (pfn == cc->migrate_pfn)
> +	if (!found_block) {
> +		cc->fast_search_fail++;
>  		pfn = reinit_migrate_pfn(cc);
> -
> +	}
>  	return pfn;
>  }
>  
> 



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock()
  2021-01-28 14:31         ` Wonhyuk Yang
@ 2021-01-28 14:40           ` Vlastimil Babka
  2021-01-28 14:49             ` Wonhyuk Yang
  0 siblings, 1 reply; 9+ messages in thread
From: Vlastimil Babka @ 2021-01-28 14:40 UTC (permalink / raw)
  To: Wonhyuk Yang, Mel Gorman; +Cc: Andrew Morton, linux-mm

On 1/28/21 3:31 PM, Wonhyuk Yang wrote:
> On Thu, Jan 28, 2021 at 11:23 PM Mel Gorman <mgorman@techsingularity.net> wrote:
>>
>> On Thu, Jan 28, 2021 at 03:01:27PM +0100, Vlastimil Babka wrote:
>> > On 1/28/21 2:50 PM, Wonhyuk Yang wrote:
>> > > On Thu, Jan 28, 2021 at 10:25 PM Mel Gorman <mgorman@techsingularity.net> wrote:
>> > >>
>> > >> As nr_scanned is post-incremented, this will still consider if the page
>> > >> should be used when the limit is reached. ++nr_scanned?
>> > >
>> > > Hi,
>> > >
>> > > Let's consider that limit is 4, nr_scanned is 0 and loop until reach the limit.
>> > > 1) pre-increment: it will search three times.(0,1,2)
>> > > 2) post-increment: it will search four times. (0,1,2,3)
>> > >
>> > > So you mean that searching three times is correct?
>> >
>> > 1) will match the outer loop's "nr_scanned < limit;" condition. It doesn't
>> > matter that much in practice, but for consistency sake, it should be 1)

Got confused there, it's 2) that matches the outer loop condition, so your patch
is fine.

>> Ok, while I find it a little strange to enter the loop and then break
>> immediately due to the limit, it's a marginal difference and in general,
>> the patch makes sense.
>>
> 
> Then, should I change post-increment to pre-increment?

IMHO, nope.

> If so, should I send a new version? It seems like it's too tiny change...






^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock()
  2021-01-28 14:40           ` Vlastimil Babka
@ 2021-01-28 14:49             ` Wonhyuk Yang
  0 siblings, 0 replies; 9+ messages in thread
From: Wonhyuk Yang @ 2021-01-28 14:49 UTC (permalink / raw)
  To: Vlastimil Babka; +Cc: Mel Gorman, Andrew Morton, linux-mm

On Thu, Jan 28, 2021 at 11:40 PM Vlastimil Babka <vbabka@suse.cz> wrote:
> >
> > Then, should I change post-increment to pre-increment?
>
> IMHO, nope.

Ok, Thanks :-)


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-01-28 14:49 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-28 13:04 [PATCH v2] mm/compactoin: Fix misbehaviors of fast_find_migrateblock() Wonhyuk Yang
2021-01-28 13:25 ` Mel Gorman
2021-01-28 13:50   ` Wonhyuk Yang
2021-01-28 14:01     ` Vlastimil Babka
2021-01-28 14:22       ` Mel Gorman
2021-01-28 14:31         ` Wonhyuk Yang
2021-01-28 14:40           ` Vlastimil Babka
2021-01-28 14:49             ` Wonhyuk Yang
2021-01-28 14:34 ` Vlastimil Babka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox