From: Joerg Roedel <joro@8bytes.org>
To: Vasant Hegde <vasant.hegde@amd.com>
Cc: Jerry Snitselaar <jsnitsel@redhat.com>,
Peng Zhang <zhangpeng.00@bytedance.com>,
Robin Murphy <robin.murphy@arm.com>,
will@kernel.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, Li Bin <huawei.libin@huawei.com>,
Xie XiuQi <xiexiuqi@huawei.com>,
Yang Yingliang <yangyingliang@huawei.com>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH] iommu: Avoid softlockup and rcu stall in fq_flush_timeout().
Date: Mon, 22 May 2023 16:58:33 +0200 [thread overview]
Message-ID: <ZGuDGftmxsF35C9P@8bytes.org> (raw)
In-Reply-To: <21f69b43-a1e7-6c84-a360-dae410bedb3f@amd.com>
Hi,
On Fri, Apr 28, 2023 at 11:14:54AM +0530, Vasant Hegde wrote:
> Ping. Any suggestion on below proposal (schedule work on each CPU to free iova)?
Optimizing the flush-timeout path seems to be working on the symptoms
rather than the cause. The main question to look into first is why are
so many CPUs competing for the IOVA allocator lock.
That is a situation which the flush-queue code is there to avoid,
obviously it does not scale to the workloads tested here. Any chance to
check why?
My guess is that the allocations are too big and not covered by the
allocation sizes supported by the flush-queue code. But maybe this is
something that can be fixed. Or the flush-queue code could even be
changed to auto-adapt to allocation patterns of the device driver?
Regards,
Joerg
next prev parent reply other threads:[~2023-05-22 14:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-16 7:11 [PATCH] iommu: Avoid softlockup and rcu stall in fq_flush_timeout() Peng Zhang
2023-04-10 22:22 ` Jerry Snitselaar
2023-04-18 10:41 ` Vasant Hegde
2023-04-28 5:44 ` Vasant Hegde
2023-05-22 14:58 ` Joerg Roedel [this message]
2023-05-22 15:18 ` Jerry Snitselaar
2023-05-22 15:35 ` John Garry
[not found] <20230216084902.1486-1-hdanton@sina.com>
2023-02-16 11:02 ` Peng Zhang
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=ZGuDGftmxsF35C9P@8bytes.org \
--to=joro@8bytes.org \
--cc=huawei.libin@huawei.com \
--cc=iommu@lists.linux.dev \
--cc=jsnitsel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@amd.com \
--cc=will@kernel.org \
--cc=xiexiuqi@huawei.com \
--cc=yangyingliang@huawei.com \
--cc=zhangpeng.00@bytedance.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