linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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.


  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