On 31/03/17 13:40, Will Deacon wrote:

Hi Robin, Joerg,

On Wed, Mar 15, 2017 at 01:33:13PM +0000, Robin Murphy wrote:

quoted

Here's the first bit of lock contention removal to chew on - feedback
welcome! Note that for the current users of the io-pgtable framework,
this is most likely to simply push more contention onto the io-pgtable
lock, so may not show a great improvement alone. Will and I both have
rough proof-of-concept implementations of lock-free io-pgtable code
which we need to sit down and agree on at some point, hopefullt fairly
soon.

I've taken the opportunity to do a bit of cleanup and refactoring
within the series to make the final state of the code nicer, but the
diffstat still turns out surprisingly reasonable in the end - it would
actually be negative but for the new comments!

Magnus, Shimoda-san, the first two patches should be of interest as they
constitute the allocation rework I mentioned a while back[1] - if you
still need to implement that scary workaround, this should make it
simple to hook IPMMU-specific calls into the alloc and free paths, and
let the driver take care of the details internally.

What's the plan for merging this? Whilst we still have the iopgtable lock
contention to resolve, this is a good incremental step towards improving
our scalability and sits nicely alongside the SMMUv2 TLB improvements I
just queued.

I was assuming this would go through the IOMMU tree if there were no
problems and the feedback was good, and that would seem to be the case.
I'm pleasantly surprised that this series doesn't even conflict at all
with my other iommu-dma changes already queued - I've just checked that
it still applies cleanly to the current iommu/next as-is.

Robin.

Thanks,

Will