From: Vlastimil Babka <vbabka@suse.cz>
To: Carlos Song <carlos.song@nxp.com>,
"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
"baolin.wang@linux.alibaba.com" <baolin.wang@linux.alibaba.com>,
"ying.huang@intel.com" <ying.huang@intel.com>,
"david@redhat.com" <david@redhat.com>,
"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
"ziy@nvidia.com" <ziy@nvidia.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Ask help about this patch c0cd6f557b90 "mm: page_alloc: fix freelist movement during block conversion"
Date: Wed, 2 Apr 2025 17:00:58 +0200 [thread overview]
Message-ID: <d9a8d187-a05f-45b1-ac4b-ed6bd04b99a5@suse.cz> (raw)
In-Reply-To: <VI2PR04MB11147E11724F867F4FCB6677DE8AF2@VI2PR04MB11147.eurprd04.prod.outlook.com>
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.
next prev parent reply other threads:[~2025-04-02 15:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 11:31 Carlos Song
2025-04-02 15:00 ` Vlastimil Babka [this message]
2025-04-03 9:17 ` Carlos Song
2025-04-02 19:44 ` Johannes Weiner
2025-04-03 9:23 ` Carlos Song
2025-04-03 21:18 ` Johannes Weiner
2025-04-07 2:45 ` Carlos Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d9a8d187-a05f-45b1-ac4b-ed6bd04b99a5@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=carlos.song@nxp.com \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=ying.huang@intel.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox