From: Nicolin Chen <nicolinc@nvidia.com>
To: Cheng-Yang Chou <yphbchou0911@gmail.com>
Cc: Pranjal Shrivastava <praan@google.com>, <will@kernel.org>,
<robin.murphy@arm.com>, <linux-arm-kernel@lists.infradead.org>,
<iommu@lists.linux.dev>, <jserv@ccns.ncku.edu.tw>
Subject: Re: [PATCH] iommu/arm-smmu-v3: Allocate cmdq_batch on the heap
Date: Thu, 12 Mar 2026 15:50:19 -0700 [thread overview]
Message-ID: <abNDK/d/8CpLhcyb@Asurada-Nvidia> (raw)
In-Reply-To: <abMEybRcTskHOjd1@eric-acer>
On Fri, Mar 13, 2026 at 02:24:09AM +0800, Cheng-Yang Chou wrote:
> On Wed, Mar 11, 2026 at 02:22:50PM +0000, Pranjal Shrivastava wrote:
> > IMO, if we really want to address these, instead of kmalloc, we could
> > potentially consider some pre-allocated per-CPU buffers (that's a lot of
> > additional book-keeping though) to keep the data off the stack or
> > something similar following a simple rule: The fast path must be
> > deterministic- no SLAB allocations and no introducing new failure points
> To resolve the stack warnings, I'm considering using per-CPU buffers in v2.
> Does this direction sound reasonable, or would you prefer to keep it as-is
> to avoid the added complexity?
I don't think per-CPU buffers would work here either..
arm_smmu_atc_inv_master() is used in a preemptible context, while
arm_smmu_atc_inv_domain() can be called from an irq context.
Think of a !SMP case for simplification: we only have one per-CPU
buffer, which is not enough if an IRQ preempts the task context.
Maybe having a smaller backup array on the stack that can be used
when the heap allocation fails? Still, I don't see how to address
it elegantly without losing some of the performance optimization.
Nicolin
next prev parent reply other threads:[~2026-03-12 22:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 9:44 [PATCH] iommu/arm-smmu-v3: Allocate cmdq_batch on the heap Cheng-Yang Chou
2026-03-11 14:22 ` Pranjal Shrivastava
2026-03-12 18:24 ` Cheng-Yang Chou
2026-03-12 22:50 ` Nicolin Chen [this message]
2026-03-13 0:06 ` Pranjal Shrivastava
2026-03-17 13:38 ` Robin Murphy
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=abNDK/d/8CpLhcyb@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jserv@ccns.ncku.edu.tw \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
--cc=yphbchou0911@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.