| Message ID | 20201220082754.6900-1-bhe@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fix the incorrect memmep defer init handling and do some cleanup | expand |
On Sun, 20 Dec 2020 16:27:49 +0800 Baoquan He <bhe@redhat.com> wrote: > VMware reported the performance regression during memmap_init() invocation. > And they bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over > memblock regions rather that check each PFN") causing it. > > https://lore.kernel.org/linux-mm/DM6PR05MB52921FF90FA01CC337DD23A1A4080@DM6PR05MB5292.namprd05.prod.outlook.com/ > > After investigation, it's caused by incorrect memmap init defer handling > in memmap_init_zone() after commit 73a6e474cb376. The current > memmap_init_zone() only handle one memory region of one zone, while > memmap_init() iterates over all its memory regions and pass them one by > one into memmap_init_zone() to handle. > > So in this patchset, patch 1/5 fixes the bug observed by VMware. Patch > 2~5/5 clean up codes. > accordingly. This series doesn't apply well to current mainline (plus, perhaps, material which I sent to Linus today). So please check all that against mainline in a day or so, refresh, retest and resend. Please separate the fix for the performance regression (1/5) into a single standalone patch, ready for -stable backporting. And then a separate 4-patch series with the cleanups for a 5.11 merge. Thanks.
On 12/22/20 at 05:46pm, Andrew Morton wrote: > On Sun, 20 Dec 2020 16:27:49 +0800 Baoquan He <bhe@redhat.com> wrote: > > > VMware reported the performance regression during memmap_init() invocation. > > And they bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over > > memblock regions rather that check each PFN") causing it. > > > > https://lore.kernel.org/linux-mm/DM6PR05MB52921FF90FA01CC337DD23A1A4080@DM6PR05MB5292.namprd05.prod.outlook.com/ > > > > After investigation, it's caused by incorrect memmap init defer handling > > in memmap_init_zone() after commit 73a6e474cb376. The current > > memmap_init_zone() only handle one memory region of one zone, while > > memmap_init() iterates over all its memory regions and pass them one by > > one into memmap_init_zone() to handle. > > > > So in this patchset, patch 1/5 fixes the bug observed by VMware. Patch > > 2~5/5 clean up codes. > > accordingly. > > This series doesn't apply well to current mainline (plus, perhaps, > material which I sent to Linus today). > > So please check all that against mainline in a day or so, refresh, > retest and resend. > > Please separate the fix for the performance regression (1/5) into a > single standalone patch, ready for -stable backporting. And then a > separate 4-patch series with the cleanups for a 5.11 merge. Sure, doing now. By the way, when sending patches to linux-mm ML, which branch should I rebase them on? I usually take your akpm/master as base, thought this will make your patch picking easier. Seems my understanding is not true, akpm/master is changed very soon, we should always base patch on linus's master branch, whether patch is sending to linux-mm or not, right? Thanks Baoquan
On 12/23/20 at 10:05am, Baoquan He wrote: > On 12/22/20 at 05:46pm, Andrew Morton wrote: > > On Sun, 20 Dec 2020 16:27:49 +0800 Baoquan He <bhe@redhat.com> wrote: > > > > > VMware reported the performance regression during memmap_init() invocation. > > > And they bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over > > > memblock regions rather that check each PFN") causing it. > > > > > > https://lore.kernel.org/linux-mm/DM6PR05MB52921FF90FA01CC337DD23A1A4080@DM6PR05MB5292.namprd05.prod.outlook.com/ > > > > > > After investigation, it's caused by incorrect memmap init defer handling > > > in memmap_init_zone() after commit 73a6e474cb376. The current > > > memmap_init_zone() only handle one memory region of one zone, while > > > memmap_init() iterates over all its memory regions and pass them one by > > > one into memmap_init_zone() to handle. > > > > > > So in this patchset, patch 1/5 fixes the bug observed by VMware. Patch > > > 2~5/5 clean up codes. > > > accordingly. > > > > This series doesn't apply well to current mainline (plus, perhaps, > > material which I sent to Linus today). > > > > So please check all that against mainline in a day or so, refresh, > > retest and resend. > > > > Please separate the fix for the performance regression (1/5) into a > > single standalone patch, ready for -stable backporting. And then a > > separate 4-patch series with the cleanups for a 5.11 merge. Have sent the 1/5 as a standalone patch. Will send the rest 4 patches as a patchset once the patch 1/5 is merged into linux-next. Thanks, Andrew. > > Sure, doing now. > > By the way, when sending patches to linux-mm ML, which branch should I > rebase them on? I usually take your akpm/master as base, thought this > will make your patch picking easier. Seems my understanding is not true, > akpm/master is changed very soon, we should always base patch on linus's > master branch, whether patch is sending to linux-mm or not, right?
VMware reported the performance regression during memmap_init() invocation. And they bisected to commit 73a6e474cb376 ("mm: memmap_init: iterate over memblock regions rather that check each PFN") causing it. https://lore.kernel.org/linux-mm/DM6PR05MB52921FF90FA01CC337DD23A1A4080@DM6PR05MB5292.namprd05.prod.outlook.com/ After investigation, it's caused by incorrect memmap init defer handling in memmap_init_zone() after commit 73a6e474cb376. The current memmap_init_zone() only handle one memory region of one zone, while memmap_init() iterates over all its memory regions and pass them one by one into memmap_init_zone() to handle. So in this patchset, patch 1/5 fixes the bug observed by VMware. Patch 2~5/5 clean up codes. accordingly. VMware helped do the testing for the patch 1 of v1 version which was based on master branch of Linus's tree on their VMware ESI platform, while the patch 1 is not changed in functionality in v2. And I haven't got a ia64 machine to compile or test, will really appreciate if anyone can help compile this patchset on one. This patchset is based on the latest next/master, only did the basic test. Baoquan He (5): mm: memmap defer init dosn't work as expected mm: rename memmap_init() and memmap_init_zone() mm: simplify parater of function memmap_init_zone() mm: simplify parameter of setup_usemap() mm: remove unneeded local variable in free_area_init_core arch/ia64/include/asm/pgtable.h | 3 +- arch/ia64/mm/init.c | 16 +++++---- include/linux/mm.h | 5 +-- mm/memory_hotplug.c | 2 +- mm/page_alloc.c | 60 ++++++++++++++++----------------- 5 files changed, 43 insertions(+), 43 deletions(-)