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

[Vlastimil Babka]

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://lore.kernel.org/linux-mm/CAJuCfpGajtAP8-kw5B5mKmhfyq6Pn67+PJgMjBeozW-qzjQMkw@xxxxxxxxxxxxxx/T/
> 
> 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:

Do you have CONFIG_DEBUG_VM enabled? Or maybe what's the .config in general?

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.