From: Will Deacon <will@kernel.org>
To: Barry Song <song.bao.hua@hisilicon.com>
Cc: linuxarm@huawei.com, iommu@lists.linux-foundation.org,
robin.murphy@arm.com, hch@lst.de,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] iommu/arm-smmu-v3: expose numa_node attribute to users in sysfs
Date: Fri, 3 Jul 2020 17:21:38 +0100 [thread overview]
Message-ID: <20200703162137.GA19780@willie-the-truck> (raw)
In-Reply-To: <20200530091505.56664-1-song.bao.hua@hisilicon.com>
On Sat, May 30, 2020 at 09:15:05PM +1200, Barry Song wrote:
> As tests show the latency of dma_unmap can increase dramatically while
> calling them cross NUMA nodes, especially cross CPU packages, eg.
> 300ns vs 800ns while waiting for the completion of CMD_SYNC in an
> empty command queue. The large latency causing by remote node will
> in turn make contention of the command queue more serious, and enlarge
> the latency of DMA users within local NUMA nodes.
>
> Users might intend to enforce NUMA locality with the consideration of
> the position of SMMU. The patch provides minor benefit by presenting
> this information to users directly, as they might want to know it without
> checking hardware spec at all.
I don't think that's a very good reason to expose things to userspace.
I know sysfs shouldn't be treated as ABI, but the grim reality is that
once somebody relies on this stuff then we can't change it, so I'd
rather avoid exposing it unless it's absolutely necessary.
Thanks,
Will
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-07-03 16:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-30 9:15 [PATCH] iommu/arm-smmu-v3: expose numa_node attribute to users in sysfs Barry Song
2020-06-01 13:13 ` Robin Murphy
2020-06-01 20:43 ` Song Bao Hua (Barry Song)
2020-07-03 16:21 ` Will Deacon [this message]
2020-07-05 9:53 ` Song Bao Hua (Barry Song)
2020-07-06 8:26 ` Jonathan Cameron
2020-07-08 6:28 ` Brice Goglin
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=20200703162137.GA19780@willie-the-truck \
--to=will@kernel.org \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=robin.murphy@arm.com \
--cc=song.bao.hua@hisilicon.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;
as well as URLs for NNTP newsgroup(s).