[PATCH] arm64: Enable PCI write-combine resources under sysfs
Clint Sbisa
csbisa at amazon.com
Tue Sep 15 19:12:13 EDT 2020
On Wed, Sep 16, 2020 at 09:00:09AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2020-09-15 at 11:18 +0100, Lorenzo Pieralisi wrote:
> > To sum it up:
> >
> > (1) RDMA drivers need a new mapping function/attribute to define their
> > message push model. Actually the message model is not necessarily related
> > to write combining a la x86, so we should probably come up with a better
> > and consistent naming. Enabling this patchset may trigger performance
> > regressions on mellanox drivers on arm64 - this ought to be addressed.
>
> I doubt it. Besides Mellanox will probably enable WC already through
> the other code path (the use of this accessor is only one of the path
> that enables the driver to do WC).
>
> I don't think we need to solve the RDMA semantics issue that urgently
> TBH, and it's definitely an orthogonal issue to that at hand.
>
> > (2) User-space/passthrough drivers rely on VFIO for BAR mappings. Since
> > it looks relevant, WC message model semantics should be introduced
> > there, somehow.
>
> Yes.
I will ping some folks on the VFIO patch to see if we can get the ball rolling
there again.
>
> > (3) Given the above, the sysfs interface can be enabled. I still don't
> > see the advantages (other than saying it is there for other arches, ie
> > what can you really do with the sysfs mappings - see Jason's VFIO/DMA
> > query) but we can do it. Still, I am not happy about the possible
> > mellanox regressions - that should be tested/verified before this
> > patch is merged IMHO. Do we really need it for v5.10 ?
>
> I don't think there's a significant risk of regression, but then I also
> dont' have a way to test :-)
I'm going to re-submit this patch to Catalin and Will with an updated commit
message capturing the context from this discussion (and cc everyone involved).
As for the whole device GRE / new naming context-- I'll have to defer to
Lorenzo on suggested next steps on this front.
Thanks,
Clint
More information about the linux-arm-kernel
mailing list