| Message ID | 20241213081618.53458-1-zhouzihan30@jd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [V1] mm: fix bug in some memory information update | expand |
* zhouzihan30 <15645113830zzh@gmail.com> [241213 03:17]: The subject of this patch is really poor. "some memory information"? considering the text below is so much more descriptive, could we have a meaningful subject? You will not get the proper people looking at this without a decent subject. At least make it "mm/page_alloc" ? > In the kernel, the zone's lowmem_reserve and _watermark, and the global > variable 'totalreserve_pages' depend on the value of managed_pages, > but after running adjust_managed_page_count, these values didn't updated, > which caused some problems. > > For example, in a system with six 1GB large pages, we found that the value > of protection in zoneinfo (zone->lowmem_reserve), is not right. > Its value seems calculated from the initial managed_pages, > but after the managed_pages changed, was not updated. Only after reading > the file /proc/sys/vm/lowmem_reserve_ratio, updates happen. > > read file /proc/sys/vm/lowmem_reserve_ratio: > > lowmem_reserve_ratio_sysctl_handler > ----setup_per_zone_lowmem_reserve > --------calculate_totalreserve_pages > > protection changed after reading file: > > [root@test ~]# cat /proc/zoneinfo | grep protection > protection: (0, 2719, 57360, 0) > protection: (0, 0, 54640, 0) > protection: (0, 0, 0, 0) > protection: (0, 0, 0, 0) > [root@test ~]# cat /proc/sys/vm/lowmem_reserve_ratio > 256 256 32 0 > [root@test ~]# cat /proc/zoneinfo | grep protection > protection: (0, 2735, 63524, 0) > protection: (0, 0, 60788, 0) > protection: (0, 0, 0, 0) > protection: (0, 0, 0, 0) > > lowmem_reserve increased also makes the totalreserve_pages increased, > which causes a decrease in available memory. The one above is just a > test machine, and the increase is not significant. On our online machine, > the reserved memory will increase by several GB due to reading this file. > It is clearly unreasonable to cause a sharp drop in available memory just > by reading a file. > > In this patch, we update reserve memory when update managed_pages, The > size of reserved memory becomes stable. But it seems that the _watermark > should also be updated along with the managed_pages. We have not done > it because we are unsure if it is reasonable to set the watermark through > the initial managed_pages. If it is not reasonable, we will propose > new patch. > > Signed-off-by: zhouzihan30 <zhouzihan30@jd.com> > Signed-off-by: yaowenchao1 <yaowenchao@jd.com> Who are these people, really? https://www.kernel.org/doc/html/v6.12/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin Also, the Signed-off-by doesn't match the sending email (gmail vs jd.com)? > --- > mm/page_alloc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index b6958333054d..b23e128afbcd 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5826,10 +5826,13 @@ __meminit void zone_pcp_init(struct zone *zone) > zone->present_pages, zone_batchsize(zone)); > } > > +static void setup_per_zone_lowmem_reserve(void); > + > void adjust_managed_page_count(struct page *page, long count) > { > atomic_long_add(count, &page_zone(page)->managed_pages); > totalram_pages_add(count); > + setup_per_zone_lowmem_reserve(); > } > EXPORT_SYMBOL(adjust_managed_page_count); > > -- > 2.33.0 > >
Thank you for your reply. The title of this patch is indeed not good. We are planning to rename it as "mm: page_alloc: fix missed updates of lowmem_reserve in adjust_managed_page_count". Is it OK? < The subject of this patch is really poor. "some memory information"? < < considering the text below is so much more descriptive, could we have a < meaningful subject? You will not get the proper people looking at this < without a decent subject. At least make it "mm/page_alloc" ? Regarding Signed-off-by, we are sorry that we do not have a particular good way. When we are on the intranet, we use jd.com email. However, this email cannot send emails externally, so we used our own Gmail as the sending email. My name is Zihan Zhou, and zhouzihan30 is my internal ERP. I also rely on this account to submit information on the intranet. Do we have to prepare a new account for kernel submission? < Who are these people, really? < < https://www.kernel.org/doc/html/v6.12/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin < < Also, the Signed-off-by doesn't match the sending email (gmail vs < jd.com)?
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index b6958333054d..b23e128afbcd 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5826,10 +5826,13 @@ __meminit void zone_pcp_init(struct zone *zone) zone->present_pages, zone_batchsize(zone)); } +static void setup_per_zone_lowmem_reserve(void); + void adjust_managed_page_count(struct page *page, long count) { atomic_long_add(count, &page_zone(page)->managed_pages); totalram_pages_add(count); + setup_per_zone_lowmem_reserve(); } EXPORT_SYMBOL(adjust_managed_page_count);
In the kernel, the zone's lowmem_reserve and _watermark, and the global variable 'totalreserve_pages' depend on the value of managed_pages, but after running adjust_managed_page_count, these values didn't updated, which caused some problems. For example, in a system with six 1GB large pages, we found that the value of protection in zoneinfo (zone->lowmem_reserve), is not right. Its value seems calculated from the initial managed_pages, but after the managed_pages changed, was not updated. Only after reading the file /proc/sys/vm/lowmem_reserve_ratio, updates happen. read file /proc/sys/vm/lowmem_reserve_ratio: lowmem_reserve_ratio_sysctl_handler ----setup_per_zone_lowmem_reserve --------calculate_totalreserve_pages protection changed after reading file: [root@test ~]# cat /proc/zoneinfo | grep protection protection: (0, 2719, 57360, 0) protection: (0, 0, 54640, 0) protection: (0, 0, 0, 0) protection: (0, 0, 0, 0) [root@test ~]# cat /proc/sys/vm/lowmem_reserve_ratio 256 256 32 0 [root@test ~]# cat /proc/zoneinfo | grep protection protection: (0, 2735, 63524, 0) protection: (0, 0, 60788, 0) protection: (0, 0, 0, 0) protection: (0, 0, 0, 0) lowmem_reserve increased also makes the totalreserve_pages increased, which causes a decrease in available memory. The one above is just a test machine, and the increase is not significant. On our online machine, the reserved memory will increase by several GB due to reading this file. It is clearly unreasonable to cause a sharp drop in available memory just by reading a file. In this patch, we update reserve memory when update managed_pages, The size of reserved memory becomes stable. But it seems that the _watermark should also be updated along with the managed_pages. We have not done it because we are unsure if it is reasonable to set the watermark through the initial managed_pages. If it is not reasonable, we will propose new patch. Signed-off-by: zhouzihan30 <zhouzihan30@jd.com> Signed-off-by: yaowenchao1 <yaowenchao@jd.com> --- mm/page_alloc.c | 3 +++ 1 file changed, 3 insertions(+)