| Message ID | 20240906095049.3486-1-urezki@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/vmalloc.c: Use "high-order" in description non 0-order pages | expand |
On 09/06/24 at 11:50am, Uladzislau Rezki (Sony) wrote: > In many places, in the comments, we use both "higher-order" and > "high-order" to describe the non 0-order pages. That is confusing, > because a "higher-order" statement does not reflect what it is > compared with. > > Suggested-by: Baoquan He <bhe@redhat.com> > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > --- > mm/vmalloc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) This looks good to me, thanks. Reviewed-by: Baoquan He <bhe@redhat.com> By the way, do you plan to clean up the rest of them in other places? > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 37b6e987234e..c7bd8740b8a2 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -3590,7 +3590,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, > break; > > /* > - * Higher order allocations must be able to be treated as > + * High-order allocations must be able to be treated as > * independent small pages by callers (as they can with > * small-page vmallocs). Some drivers do their own refcounting > * on vmalloc_to_page() pages, some use page->mapping, > @@ -3653,7 +3653,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, > page_order = vm_area_page_order(area); > > /* > - * Higher order nofail allocations are really expensive and > + * High-order nofail allocations are really expensive and > * potentially dangerous (pre-mature OOM, disruptive reclaim > * and compaction etc. > * > -- > 2.39.2 >
On Mon, Sep 09, 2024 at 10:56:57AM +0800, Baoquan He wrote: > On 09/06/24 at 11:50am, Uladzislau Rezki (Sony) wrote: > > In many places, in the comments, we use both "higher-order" and > > "high-order" to describe the non 0-order pages. That is confusing, > > because a "higher-order" statement does not reflect what it is > > compared with. > > > > Suggested-by: Baoquan He <bhe@redhat.com> > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > > --- > > mm/vmalloc.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > This looks good to me, thanks. > > Reviewed-by: Baoquan He <bhe@redhat.com> > > By the way, do you plan to clean up the rest of them in other places? > urezki@pc638:~/data/raid0/coding/linux-next.git$ grep -rni higher include/linux/vmalloc.h urezki@pc638:~/data/raid0/coding/linux-next.git$ grep -rni higher mm/vmalloc.c 493: * nr is a running index into the array which helps higher level urezki@pc638:~/data/raid0/coding/linux-next.git$ What am i missing? Didn't i do it? -- Uladzislau Rezki
On 09/09/24 at 07:52pm, Uladzislau Rezki wrote: > On Mon, Sep 09, 2024 at 10:56:57AM +0800, Baoquan He wrote: > > On 09/06/24 at 11:50am, Uladzislau Rezki (Sony) wrote: > > > In many places, in the comments, we use both "higher-order" and > > > "high-order" to describe the non 0-order pages. That is confusing, > > > because a "higher-order" statement does not reflect what it is > > > compared with. > > > > > > Suggested-by: Baoquan He <bhe@redhat.com> > > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > > > --- > > > mm/vmalloc.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > This looks good to me, thanks. > > > > Reviewed-by: Baoquan He <bhe@redhat.com> > > > > By the way, do you plan to clean up the rest of them in other places? > > > urezki@pc638:~/data/raid0/coding/linux-next.git$ grep -rni higher include/linux/vmalloc.h > urezki@pc638:~/data/raid0/coding/linux-next.git$ grep -rni higher mm/vmalloc.c > 493: * nr is a running index into the array which helps higher level > urezki@pc638:~/data/raid0/coding/linux-next.git$ > > What am i missing? Didn't i do it? Sorry, I didn't make it clear. I meant those places other than vmalloc related files, e.g mm/page_alloc.c, there are a lot of [Hhigh]er-order mixed with high-order. I can continue the cleaning sometime if it's not in your TO-DO list. mm/page_alloc.c:551: * Higher-order pages are called "compound pages". They are structured thusly: mm/page_alloc.c:716: * of the next-higher order is free. If it is, it's possible mm/page_alloc.c:720: * as a 2-level higher order page mm/page_alloc.c:735: return find_buddy_page_pfn(higher_page, higher_page_pfn, order + 1, mm/page_alloc.c:2750: * split_page takes a non-compound higher-order page, and splits it into mm/page_alloc.c:3587: /* The OOM killer will not help higher order allocs */ mm/page_alloc.c:4811: * within a 0 or higher order page. Multiple fragments within that page mm/page_alloc.c:6516: * page allocator holds, ie. they can be part of higher order mm/page_alloc.c:6790: * Break down a higher-order page in sub-pages, and keep our target out of
On Tue, Sep 10, 2024 at 08:40:42AM +0800, Baoquan He wrote: > On 09/09/24 at 07:52pm, Uladzislau Rezki wrote: > > On Mon, Sep 09, 2024 at 10:56:57AM +0800, Baoquan He wrote: > > > On 09/06/24 at 11:50am, Uladzislau Rezki (Sony) wrote: > > > > In many places, in the comments, we use both "higher-order" and > > > > "high-order" to describe the non 0-order pages. That is confusing, > > > > because a "higher-order" statement does not reflect what it is > > > > compared with. > > > > > > > > Suggested-by: Baoquan He <bhe@redhat.com> > > > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > > > > --- > > > > mm/vmalloc.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > This looks good to me, thanks. > > > > > > Reviewed-by: Baoquan He <bhe@redhat.com> > > > > > > By the way, do you plan to clean up the rest of them in other places? > > > > > urezki@pc638:~/data/raid0/coding/linux-next.git$ grep -rni higher include/linux/vmalloc.h > > urezki@pc638:~/data/raid0/coding/linux-next.git$ grep -rni higher mm/vmalloc.c > > 493: * nr is a running index into the array which helps higher level > > urezki@pc638:~/data/raid0/coding/linux-next.git$ > > > > What am i missing? Didn't i do it? > > Sorry, I didn't make it clear. I meant those places other than vmalloc > related files, e.g mm/page_alloc.c, there are a lot of [Hhigh]er-order > mixed with high-order. I can continue the cleaning sometime if it's not > in your TO-DO list. > > mm/page_alloc.c:551: * Higher-order pages are called "compound pages". They are structured thusly: > mm/page_alloc.c:716: * of the next-higher order is free. If it is, it's possible > mm/page_alloc.c:720: * as a 2-level higher order page > mm/page_alloc.c:735: return find_buddy_page_pfn(higher_page, higher_page_pfn, order + 1, > mm/page_alloc.c:2750: * split_page takes a non-compound higher-order page, and splits it into > mm/page_alloc.c:3587: /* The OOM killer will not help higher order allocs */ > mm/page_alloc.c:4811: * within a 0 or higher order page. Multiple fragments within that page > mm/page_alloc.c:6516: * page allocator holds, ie. they can be part of higher order > mm/page_alloc.c:6790: * Break down a higher-order page in sub-pages, and keep our target out of > I see. I appreciate if you go ahead and improve it further. -- Uladzislau Rezki
On 09/10/24 at 10:57am, Uladzislau Rezki wrote: > On Tue, Sep 10, 2024 at 08:40:42AM +0800, Baoquan He wrote: > > On 09/09/24 at 07:52pm, Uladzislau Rezki wrote: > > > On Mon, Sep 09, 2024 at 10:56:57AM +0800, Baoquan He wrote: > > > > On 09/06/24 at 11:50am, Uladzislau Rezki (Sony) wrote: > > > > > In many places, in the comments, we use both "higher-order" and > > > > > "high-order" to describe the non 0-order pages. That is confusing, > > > > > because a "higher-order" statement does not reflect what it is > > > > > compared with. > > > > > > > > > > Suggested-by: Baoquan He <bhe@redhat.com> > > > > > Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> > > > > > --- > > > > > mm/vmalloc.c | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > This looks good to me, thanks. > > > > > > > > Reviewed-by: Baoquan He <bhe@redhat.com> > > > > > > > > By the way, do you plan to clean up the rest of them in other places? > > > > > > > urezki@pc638:~/data/raid0/coding/linux-next.git$ grep -rni higher include/linux/vmalloc.h > > > urezki@pc638:~/data/raid0/coding/linux-next.git$ grep -rni higher mm/vmalloc.c > > > 493: * nr is a running index into the array which helps higher level > > > urezki@pc638:~/data/raid0/coding/linux-next.git$ > > > > > > What am i missing? Didn't i do it? > > > > Sorry, I didn't make it clear. I meant those places other than vmalloc > > related files, e.g mm/page_alloc.c, there are a lot of [Hhigh]er-order > > mixed with high-order. I can continue the cleaning sometime if it's not > > in your TO-DO list. > > > > mm/page_alloc.c:551: * Higher-order pages are called "compound pages". They are structured thusly: > > mm/page_alloc.c:716: * of the next-higher order is free. If it is, it's possible > > mm/page_alloc.c:720: * as a 2-level higher order page > > mm/page_alloc.c:735: return find_buddy_page_pfn(higher_page, higher_page_pfn, order + 1, > > mm/page_alloc.c:2750: * split_page takes a non-compound higher-order page, and splits it into > > mm/page_alloc.c:3587: /* The OOM killer will not help higher order allocs */ > > mm/page_alloc.c:4811: * within a 0 or higher order page. Multiple fragments within that page > > mm/page_alloc.c:6516: * page allocator holds, ie. they can be part of higher order > > mm/page_alloc.c:6790: * Break down a higher-order page in sub-pages, and keep our target out of > > > I see. I appreciate if you go ahead and improve it further. Ok, will do later.
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 37b6e987234e..c7bd8740b8a2 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3590,7 +3590,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, break; /* - * Higher order allocations must be able to be treated as + * High-order allocations must be able to be treated as * independent small pages by callers (as they can with * small-page vmallocs). Some drivers do their own refcounting * on vmalloc_to_page() pages, some use page->mapping, @@ -3653,7 +3653,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, page_order = vm_area_page_order(area); /* - * Higher order nofail allocations are really expensive and + * High-order nofail allocations are really expensive and * potentially dangerous (pre-mature OOM, disruptive reclaim * and compaction etc. *
In many places, in the comments, we use both "higher-order" and "high-order" to describe the non 0-order pages. That is confusing, because a "higher-order" statement does not reflect what it is compared with. Suggested-by: Baoquan He <bhe@redhat.com> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com> --- mm/vmalloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)