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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d9a8d187-a05f-45b1-ac4b-ed6bd04b99a5@suse.cz>
Date: Wed, 2 Apr 2025 17:00:58 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Carlos Song <carlos.song@....com>, "hannes@...xchg.org"
 <hannes@...xchg.org>,
 "baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
 "ying.huang@...el.com" <ying.huang@...el.com>,
 "david@...hat.com" <david@...hat.com>,
 "mgorman@...hsingularity.net" <mgorman@...hsingularity.net>,
 "ziy@...dia.com" <ziy@...dia.com>,
 "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Cc: "linux-mm@...ck.org" <linux-mm@...ck.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Ask help about this patch c0cd6f557b90 "mm: page_alloc: fix
 freelist movement during block conversion"

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@mail.gmail.com/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.