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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <VI2PR04MB111478EE6156B444B978C799EE8AE2@VI2PR04MB11147.eurprd04.prod.outlook.com>
Date: Thu, 3 Apr 2025 09:17:25 +0000
From: Carlos Song <carlos.song@....com>
To: Vlastimil Babka <vbabka@...e.cz>, "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"



> -----Original Message-----
> From: Vlastimil Babka <vbabka@...e.cz>
> Sent: Wednesday, April 2, 2025 11:01 PM
> To: Carlos Song <carlos.song@....com>; hannes@...xchg.org;
> baolin.wang@...ux.alibaba.com; ying.huang@...el.com; david@...hat.com;
> mgorman@...hsingularity.net; ziy@...dia.com; akpm@...ux-foundation.org
> Cc: linux-mm@...ck.org; linux-kernel@...r.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.