* [PATCH] mm/page_isolation: do not isolate the max order page @ 2020-12-02 12:21 Muchun Song 2020-12-03 0:03 ` Vlastimil Babka 2020-12-03 16:27 ` David Hildenbrand 0 siblings, 2 replies; 9+ messages in thread From: Muchun Song @ 2020-12-02 12:21 UTC (permalink / raw) To: akpm; +Cc: linux-mm, linux-kernel, Muchun Song The max order page has no buddy page and never merge to other order. So isolating and then freeing it is pointless. Signed-off-by: Muchun Song <songmuchun@bytedance.com> --- mm/page_isolation.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_isolation.c b/mm/page_isolation.c index a254e1f370a3..bddf788f45bf 100644 --- a/mm/page_isolation.c +++ b/mm/page_isolation.c @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) */ if (PageBuddy(page)) { order = buddy_order(page); - if (order >= pageblock_order) { + if (order >= pageblock_order && order < MAX_ORDER - 1) { pfn = page_to_pfn(page); buddy_pfn = __find_buddy_pfn(pfn, order); buddy = page + (buddy_pfn - pfn); -- 2.11.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/page_isolation: do not isolate the max order page 2020-12-02 12:21 [PATCH] mm/page_isolation: do not isolate the max order page Muchun Song @ 2020-12-03 0:03 ` Vlastimil Babka 2020-12-03 2:43 ` [External] " Muchun Song 2020-12-03 16:26 ` David Hildenbrand 2020-12-03 16:27 ` David Hildenbrand 1 sibling, 2 replies; 9+ messages in thread From: Vlastimil Babka @ 2020-12-03 0:03 UTC (permalink / raw) To: Muchun Song, akpm; +Cc: linux-mm, linux-kernel, Joonsoo Kim On 12/2/20 1:21 PM, Muchun Song wrote: > The max order page has no buddy page and never merge to other order. > So isolating and then freeing it is pointless. > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> > --- > mm/page_isolation.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/page_isolation.c b/mm/page_isolation.c > index a254e1f370a3..bddf788f45bf 100644 > --- a/mm/page_isolation.c > +++ b/mm/page_isolation.c > @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) > */ > if (PageBuddy(page)) { > order = buddy_order(page); > - if (order >= pageblock_order) { > + if (order >= pageblock_order && order < MAX_ORDER - 1) { > pfn = page_to_pfn(page); > buddy_pfn = __find_buddy_pfn(pfn, order); > buddy = page + (buddy_pfn - pfn); Hm I wonder if order == MAX_ORDER - 1, then the buddy can actually be a !pfn_valid() in some corner case? pfn_valid_within(buddy_pfn) that follows would only catch it on archs with holes in zone. Then is_migrate_isolate_page(buddy) might access an invalid buddy. So this might be actually a bug fix and not just optimization, just the bug hasn't been observed in practice. > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] Re: [PATCH] mm/page_isolation: do not isolate the max order page 2020-12-03 0:03 ` Vlastimil Babka @ 2020-12-03 2:43 ` Muchun Song 2020-12-03 15:49 ` Vlastimil Babka 2020-12-03 16:26 ` David Hildenbrand 1 sibling, 1 reply; 9+ messages in thread From: Muchun Song @ 2020-12-03 2:43 UTC (permalink / raw) To: Vlastimil Babka Cc: Andrew Morton, Linux Memory Management List, LKML, Joonsoo Kim On Thu, Dec 3, 2020 at 8:03 AM Vlastimil Babka <vbabka@suse.cz> wrote: > > On 12/2/20 1:21 PM, Muchun Song wrote: > > The max order page has no buddy page and never merge to other order. > > So isolating and then freeing it is pointless. > > > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > > Acked-by: Vlastimil Babka <vbabka@suse.cz> > > > --- > > mm/page_isolation.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/page_isolation.c b/mm/page_isolation.c > > index a254e1f370a3..bddf788f45bf 100644 > > --- a/mm/page_isolation.c > > +++ b/mm/page_isolation.c > > @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) > > */ > > if (PageBuddy(page)) { > > order = buddy_order(page); > > - if (order >= pageblock_order) { > > + if (order >= pageblock_order && order < MAX_ORDER - 1) { > > pfn = page_to_pfn(page); > > buddy_pfn = __find_buddy_pfn(pfn, order); > > buddy = page + (buddy_pfn - pfn); > > Hm I wonder if order == MAX_ORDER - 1, then the buddy can actually be a > !pfn_valid() in some corner case? pfn_valid_within(buddy_pfn) that follows would > only catch it on archs with holes in zone. Then is_migrate_isolate_page(buddy) > might access an invalid buddy. So this might be actually a bug fix and not just > optimization, just the bug hasn't been observed in practice. Agree. Should we add a Fixes tag in the commit log? Thanks. > > > > -- Yours, Muchun ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [External] Re: [PATCH] mm/page_isolation: do not isolate the max order page 2020-12-03 2:43 ` [External] " Muchun Song @ 2020-12-03 15:49 ` Vlastimil Babka 0 siblings, 0 replies; 9+ messages in thread From: Vlastimil Babka @ 2020-12-03 15:49 UTC (permalink / raw) To: Muchun Song Cc: Andrew Morton, Linux Memory Management List, LKML, Joonsoo Kim On 12/3/20 3:43 AM, Muchun Song wrote: > On Thu, Dec 3, 2020 at 8:03 AM Vlastimil Babka <vbabka@suse.cz> wrote: >> >> On 12/2/20 1:21 PM, Muchun Song wrote: >> > The max order page has no buddy page and never merge to other order. >> > So isolating and then freeing it is pointless. >> > >> > Signed-off-by: Muchun Song <songmuchun@bytedance.com> >> >> Acked-by: Vlastimil Babka <vbabka@suse.cz> >> >> > --- >> > mm/page_isolation.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c >> > index a254e1f370a3..bddf788f45bf 100644 >> > --- a/mm/page_isolation.c >> > +++ b/mm/page_isolation.c >> > @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) >> > */ >> > if (PageBuddy(page)) { >> > order = buddy_order(page); >> > - if (order >= pageblock_order) { >> > + if (order >= pageblock_order && order < MAX_ORDER - 1) { >> > pfn = page_to_pfn(page); >> > buddy_pfn = __find_buddy_pfn(pfn, order); >> > buddy = page + (buddy_pfn - pfn); >> >> Hm I wonder if order == MAX_ORDER - 1, then the buddy can actually be a >> !pfn_valid() in some corner case? pfn_valid_within(buddy_pfn) that follows would >> only catch it on archs with holes in zone. Then is_migrate_isolate_page(buddy) >> might access an invalid buddy. So this might be actually a bug fix and not just >> optimization, just the bug hasn't been observed in practice. > > Agree. Should we add a Fixes tag in the commit log? Thanks. Right. Fixes: 3c605096d315 ("mm/page_alloc: restrict max order of merging on isolated pageblock") The criteria for CC stable is not met though as it's theoretical. >> >> > >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/page_isolation: do not isolate the max order page 2020-12-03 0:03 ` Vlastimil Babka 2020-12-03 2:43 ` [External] " Muchun Song @ 2020-12-03 16:26 ` David Hildenbrand 2020-12-03 17:15 ` Vlastimil Babka 1 sibling, 1 reply; 9+ messages in thread From: David Hildenbrand @ 2020-12-03 16:26 UTC (permalink / raw) To: Vlastimil Babka, Muchun Song, akpm; +Cc: linux-mm, linux-kernel, Joonsoo Kim On 03.12.20 01:03, Vlastimil Babka wrote: > On 12/2/20 1:21 PM, Muchun Song wrote: >> The max order page has no buddy page and never merge to other order. >> So isolating and then freeing it is pointless. >> >> Signed-off-by: Muchun Song <songmuchun@bytedance.com> > > Acked-by: Vlastimil Babka <vbabka@suse.cz> > >> --- >> mm/page_isolation.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/page_isolation.c b/mm/page_isolation.c >> index a254e1f370a3..bddf788f45bf 100644 >> --- a/mm/page_isolation.c >> +++ b/mm/page_isolation.c >> @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) >> */ >> if (PageBuddy(page)) { >> order = buddy_order(page); >> - if (order >= pageblock_order) { >> + if (order >= pageblock_order && order < MAX_ORDER - 1) { >> pfn = page_to_pfn(page); >> buddy_pfn = __find_buddy_pfn(pfn, order); >> buddy = page + (buddy_pfn - pfn); > > Hm I wonder if order == MAX_ORDER - 1, then the buddy can actually be a > !pfn_valid() in some corner case? pfn_valid_within(buddy_pfn) that follows would > only catch it on archs with holes in zone. Then is_migrate_isolate_page(buddy) > might access an invalid buddy. So this might be actually a bug fix and not just > optimization, just the bug hasn't been observed in practice. I think we have no users that isolate/unisolate close to holes. CMA regions are properly aligned (to max of page_order / max_order_nr_pages) and don't contain holes. virtio-mem does not apply as it knows its range has no holes. gigantic pages are aligned naturally and we check that there are no holes upfront. There are no other users. I don't see a need for stable/fixes. -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/page_isolation: do not isolate the max order page 2020-12-03 16:26 ` David Hildenbrand @ 2020-12-03 17:15 ` Vlastimil Babka 2020-12-03 17:48 ` David Hildenbrand 0 siblings, 1 reply; 9+ messages in thread From: Vlastimil Babka @ 2020-12-03 17:15 UTC (permalink / raw) To: David Hildenbrand, Muchun Song, akpm; +Cc: linux-mm, linux-kernel, Joonsoo Kim On 12/3/20 5:26 PM, David Hildenbrand wrote: > On 03.12.20 01:03, Vlastimil Babka wrote: >> On 12/2/20 1:21 PM, Muchun Song wrote: >>> The max order page has no buddy page and never merge to other order. >>> So isolating and then freeing it is pointless. >>> >>> Signed-off-by: Muchun Song <songmuchun@bytedance.com> >> >> Acked-by: Vlastimil Babka <vbabka@suse.cz> >> >>> --- >>> mm/page_isolation.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c >>> index a254e1f370a3..bddf788f45bf 100644 >>> --- a/mm/page_isolation.c >>> +++ b/mm/page_isolation.c >>> @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) >>> */ >>> if (PageBuddy(page)) { >>> order = buddy_order(page); >>> - if (order >= pageblock_order) { >>> + if (order >= pageblock_order && order < MAX_ORDER - 1) { >>> pfn = page_to_pfn(page); >>> buddy_pfn = __find_buddy_pfn(pfn, order); >>> buddy = page + (buddy_pfn - pfn); >> >> Hm I wonder if order == MAX_ORDER - 1, then the buddy can actually be a >> !pfn_valid() in some corner case? pfn_valid_within(buddy_pfn) that follows would >> only catch it on archs with holes in zone. Then is_migrate_isolate_page(buddy) >> might access an invalid buddy. So this might be actually a bug fix and not just >> optimization, just the bug hasn't been observed in practice. > > I think we have no users that isolate/unisolate close to holes. > > CMA regions are properly aligned (to max of page_order / > max_order_nr_pages) and don't contain holes. The problem as I see it, is that buddy_order(page) might be already MAX_ORDER - 1 (e.g. two pageblocks on x86), and then finding buddy of that one is beyond the guaranteed alignment (if they merged, which they can't, it would be four pageblocks). Might not be just a hole within zone, but also across zone boundary? While being isolated and used pages migrated away, the freed pages shouldn't merge to MAX_ORDER-1, but if the MAX_ORDER-1 free page was already there before the isolation? > virtio-mem does not apply as it knows its range has no holes. > > gigantic pages are aligned naturally and we check that there are no > holes upfront. > > There are no other users. > > > I don't see a need for stable/fixes. > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/page_isolation: do not isolate the max order page 2020-12-03 17:15 ` Vlastimil Babka @ 2020-12-03 17:48 ` David Hildenbrand 2020-12-03 19:24 ` David Hildenbrand 0 siblings, 1 reply; 9+ messages in thread From: David Hildenbrand @ 2020-12-03 17:48 UTC (permalink / raw) To: Vlastimil Babka, Muchun Song, akpm; +Cc: linux-mm, linux-kernel, Joonsoo Kim On 03.12.20 18:15, Vlastimil Babka wrote: > On 12/3/20 5:26 PM, David Hildenbrand wrote: >> On 03.12.20 01:03, Vlastimil Babka wrote: >>> On 12/2/20 1:21 PM, Muchun Song wrote: >>>> The max order page has no buddy page and never merge to other order. >>>> So isolating and then freeing it is pointless. >>>> >>>> Signed-off-by: Muchun Song <songmuchun@bytedance.com> >>> >>> Acked-by: Vlastimil Babka <vbabka@suse.cz> >>> >>>> --- >>>> mm/page_isolation.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c >>>> index a254e1f370a3..bddf788f45bf 100644 >>>> --- a/mm/page_isolation.c >>>> +++ b/mm/page_isolation.c >>>> @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) >>>> */ >>>> if (PageBuddy(page)) { >>>> order = buddy_order(page); >>>> - if (order >= pageblock_order) { >>>> + if (order >= pageblock_order && order < MAX_ORDER - 1) { >>>> pfn = page_to_pfn(page); >>>> buddy_pfn = __find_buddy_pfn(pfn, order); >>>> buddy = page + (buddy_pfn - pfn); >>> >>> Hm I wonder if order == MAX_ORDER - 1, then the buddy can actually be a >>> !pfn_valid() in some corner case? pfn_valid_within(buddy_pfn) that follows would >>> only catch it on archs with holes in zone. Then is_migrate_isolate_page(buddy) >>> might access an invalid buddy. So this might be actually a bug fix and not just >>> optimization, just the bug hasn't been observed in practice. >> >> I think we have no users that isolate/unisolate close to holes. >> >> CMA regions are properly aligned (to max of page_order / >> max_order_nr_pages) and don't contain holes. > > The problem as I see it, is that buddy_order(page) might be already MAX_ORDER - > 1 (e.g. two pageblocks on x86), and then finding buddy of that one is beyond the > guaranteed alignment (if they merged, which they can't, it would be four Oh, I see. I would have assume that __find_buddy_pfn() would not hand out invalid buddies. But you're right, it's generic: pfn = 1024 (4M) order = MAX_ORDER - 1 = 10 buddy_pfn = __find_buddy_pfn(pfn, order) -> pfn ^ (1 << order) = 0 If that page has no struct page (!pfn_valid), we're doomed, I agree. It would be problematic if we have alloc_contig_range() users with ranges not aligned/multiples of to 8 MB (MAX_ORDER) I guess. virtio-mem and gigantic pages should be fine. CMA might be problematic, though? Do we have such small CMA ranges or with such alignment? COuld be I guess. cma_init_reserved_mem() only checks alignment = PAGE_SIZE << max_t(unsigned long, MAX_ORDER - 1, pageblock_order); > pageblocks). Might not be just a hole within zone, but also across zone boundary? > While being isolated and used pages migrated away, the freed pages shouldn't > merge to MAX_ORDER-1, but if the MAX_ORDER-1 free page was already there before > the isolation? -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/page_isolation: do not isolate the max order page 2020-12-03 17:48 ` David Hildenbrand @ 2020-12-03 19:24 ` David Hildenbrand 0 siblings, 0 replies; 9+ messages in thread From: David Hildenbrand @ 2020-12-03 19:24 UTC (permalink / raw) To: Vlastimil Babka, Muchun Song, akpm; +Cc: linux-mm, linux-kernel, Joonsoo Kim On 03.12.20 18:48, David Hildenbrand wrote: > On 03.12.20 18:15, Vlastimil Babka wrote: >> On 12/3/20 5:26 PM, David Hildenbrand wrote: >>> On 03.12.20 01:03, Vlastimil Babka wrote: >>>> On 12/2/20 1:21 PM, Muchun Song wrote: >>>>> The max order page has no buddy page and never merge to other order. >>>>> So isolating and then freeing it is pointless. >>>>> >>>>> Signed-off-by: Muchun Song <songmuchun@bytedance.com> >>>> >>>> Acked-by: Vlastimil Babka <vbabka@suse.cz> >>>> >>>>> --- >>>>> mm/page_isolation.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c >>>>> index a254e1f370a3..bddf788f45bf 100644 >>>>> --- a/mm/page_isolation.c >>>>> +++ b/mm/page_isolation.c >>>>> @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) >>>>> */ >>>>> if (PageBuddy(page)) { >>>>> order = buddy_order(page); >>>>> - if (order >= pageblock_order) { >>>>> + if (order >= pageblock_order && order < MAX_ORDER - 1) { >>>>> pfn = page_to_pfn(page); >>>>> buddy_pfn = __find_buddy_pfn(pfn, order); >>>>> buddy = page + (buddy_pfn - pfn); >>>> >>>> Hm I wonder if order == MAX_ORDER - 1, then the buddy can actually be a >>>> !pfn_valid() in some corner case? pfn_valid_within(buddy_pfn) that follows would >>>> only catch it on archs with holes in zone. Then is_migrate_isolate_page(buddy) >>>> might access an invalid buddy. So this might be actually a bug fix and not just >>>> optimization, just the bug hasn't been observed in practice. >>> >>> I think we have no users that isolate/unisolate close to holes. >>> >>> CMA regions are properly aligned (to max of page_order / >>> max_order_nr_pages) and don't contain holes. >> >> The problem as I see it, is that buddy_order(page) might be already MAX_ORDER - >> 1 (e.g. two pageblocks on x86), and then finding buddy of that one is beyond the >> guaranteed alignment (if they merged, which they can't, it would be four > > Oh, I see. I would have assume that __find_buddy_pfn() would not hand > out invalid buddies. But you're right, it's generic: > > pfn = 1024 (4M) > order = MAX_ORDER - 1 = 10 > buddy_pfn = __find_buddy_pfn(pfn, order) > > -> pfn ^ (1 << order) = 0 > > > If that page has no struct page (!pfn_valid), we're doomed, I agree. It > would be problematic if we have alloc_contig_range() users with ranges > not aligned/multiples of to 8 MB (MAX_ORDER) I guess. virtio-mem and > gigantic pages should be fine. CMA might be problematic, though? Do we > have such small CMA ranges or with such alignment? COuld be I guess. > > cma_init_reserved_mem() only checks > > alignment = PAGE_SIZE << max_t(unsigned long, MAX_ORDER - 1, > pageblock_order); > Thinking again (SPARSE), we always end up in a single memory section. Usually, all pfns within a single section are valid. The only exception is with HAVE_ARCH_PFN_VALID - arm and arm6. arm64 also has HOLES_IN_ZONE - so we always check for pfn_valid() in this code. arm only has HAVE_ARCH_PFN_VALID with SPARSE on ARCH_OMAP1. So only in that combination, we might run into that issue if I am not wrong. Not sure about !SPARSE and mips. -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] mm/page_isolation: do not isolate the max order page 2020-12-02 12:21 [PATCH] mm/page_isolation: do not isolate the max order page Muchun Song 2020-12-03 0:03 ` Vlastimil Babka @ 2020-12-03 16:27 ` David Hildenbrand 1 sibling, 0 replies; 9+ messages in thread From: David Hildenbrand @ 2020-12-03 16:27 UTC (permalink / raw) To: Muchun Song, akpm; +Cc: linux-mm, linux-kernel On 02.12.20 13:21, Muchun Song wrote: > The max order page has no buddy page and never merge to other order. > So isolating and then freeing it is pointless. > > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > --- > mm/page_isolation.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/page_isolation.c b/mm/page_isolation.c > index a254e1f370a3..bddf788f45bf 100644 > --- a/mm/page_isolation.c > +++ b/mm/page_isolation.c > @@ -88,7 +88,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype) > */ > if (PageBuddy(page)) { > order = buddy_order(page); > - if (order >= pageblock_order) { > + if (order >= pageblock_order && order < MAX_ORDER - 1) { > pfn = page_to_pfn(page); > buddy_pfn = __find_buddy_pfn(pfn, order); > buddy = page + (buddy_pfn - pfn); > Reviewed-by: David Hildenbrand <david@redhat.com> -- Thanks, David / dhildenb ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-12-03 19:25 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-02 12:21 [PATCH] mm/page_isolation: do not isolate the max order page Muchun Song 2020-12-03 0:03 ` Vlastimil Babka 2020-12-03 2:43 ` [External] " Muchun Song 2020-12-03 15:49 ` Vlastimil Babka 2020-12-03 16:26 ` David Hildenbrand 2020-12-03 17:15 ` Vlastimil Babka 2020-12-03 17:48 ` David Hildenbrand 2020-12-03 19:24 ` David Hildenbrand 2020-12-03 16:27 ` David Hildenbrand
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).