Re: Ask help about this patch c0cd6f557b90 "mm: page_alloc: fix freelist movement during block conversion"

[Carlos Song <carlos.song@nxp.com>]

> -----Original Message-----
> From: Vlastimil Babka <vbabka@suse.cz>
> Sent: Wednesday, April 2, 2025 11:01 PM
> To: Carlos Song <carlos.song@nxp.com>; hannes@cmpxchg.org;
> baolin.wang@linux.alibaba.com; ying.huang@intel.com; david@redhat.com;
> mgorman@techsingularity.net; ziy@nvidia.com; akpm@linux-foundation.org
> Cc: linux-mm@kvack.org; linux-kernel@vger.kernel.org
> Subject: [EXT] Re: Ask help about this patch c0cd6f557b90 "mm: page_alloc: fix
> freelist movement during block conversion"
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
> 
> 
> On 4/2/25 13:31, Carlos Song wrote:
> > Hi, all
> 
> Hi,
> 
> > I found a 300ms~600ms IRQ off when writing 1Gb data to storage device at
> I.MX7d SDB board at Linux-kernel-v6.14.
> > From this discussion I find the regression root cause:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Flinux-mm%2FCAJuCfpGajtAP8-kw5B5mKmhfyq6Pn67%2BPJgMj
> BeozW
> >
> -qzjQMkw%40mail.gmail.com%2FT%2F&data=05%7C02%7Ccarlos.song%40nxp
> .com%
> >
> 7C30f153ecf3234bf3619a08dd71f72e6b%7C686ea1d3bc2b4c6fa92cd99c5c301
> 635%
> >
> 7C0%7C0%7C638792028628801379%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0
> eU1hcGkiO
> >
> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> >
> 3D%3D%7C0%7C%7C%7C&sdata=hqeX9jfdbi7wcq7JZaVawvZKoD9yLGyJ9aIzGX
> pdS38%3
> > D&reserved=0
> >
> > Before add this patch c0cd6f557b90 "mm: page_alloc: fix freelist movement
> during block conversion", this longest IRQ off time is only 1ms~2ms.
> > After add this patch c0cd6f557b90 "mm: page_alloc: fix freelist movement
> during block conversion", this longest IRQ off time is only ~100ms.
> > This patch is added in linux-kernel 6.10.
> > In the same test case and environment. From 6.10, as other PATCHs are
> > added, the spinlock time gradually increases. At 6.12 the IRQ off is ~150ms and
> at 6.14, the IRQ off time is ~300ms.
> >
> > Run this cmd to test:
> > dd if=/dev/zero of=/dev/mmcblk0p3 bs=4096 seek=12500 count=256000
> > conv=fsync
> >
> > I use Ftrace irqoff tracer to trace the longest IRQ off event. Here is my test log.
> Do I trigger a bug?
> >
> > 4 Ftrace logs of irqoff tracing on the same environment using the same case
> only with different kernel version:
> > 1. Not add the patch 2. Add the patch 3. At 6.12 4. At 6.14.
> >
> > Log is here:
> 

Hi, 

Thank you for your quick ack and help!

> Do you have CONFIG_DEBUG_VM enabled? Or maybe what's the .config in
> general?
> 
I think we don't enable CONFIG_DEBUG_VM

In .config, I can see
# CONFIG_DEBUG_VM is not set

A Snapshot in .config:

CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_PER_VMA_LOCK_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SHRINKER_DEBUG is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_DEBUG_VFS is not set
# CONFIG_DEBUG_VM is not set
CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_DEBUG_KMAP_LOCAL is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_MEM_ALLOC_PROFILING is not set

Carlos Song

> I guess we do more work in __rmqueue_fallback() now under the lock but it
> should not take *that* long, hm. I'm not however sure if we can split the zone
> lock holding here.
> 
> Guess we could at least optimize account_freepages() done as part of
> __move_freepages_block() -> move_to_free_list() as the migratetypes are
> always the same so it could be a single pair of calls on an accumulated nr_pages
> count instead of pair for every page moved. And the loop in
> __move_freepages_block() could have an extra struct page * iterator instead of
> pfn_to_page() in every iteration.