Re: [PATCHv9 RFC 1/3] Break up monolithic iommu table/lock into finer graularity pools and lock

2015-04-08 Thread Sowmini Varadhan
On (04/08/15 18:30), Benjamin Herrenschmidt wrote: > > I'm happy with your last version, feel free to add my > > Acked-by: Benjamin Herrenschmidt sounds good, I'll do this and rese a non-RFC version today. Thanks for all the feedback - it was very useful to me, and I'm much happier with the en

Re: [PATCHv9 RFC 1/3] Break up monolithic iommu table/lock into finer graularity pools and lock

2015-04-08 Thread Benjamin Herrenschmidt
On Sun, 2015-04-05 at 07:49 -0400, Sowmini Varadhan wrote: > Investigation of multithreaded iperf experiments on an ethernet > interface show the iommu->lock as the hottest lock identified by > lockstat, with something of the order of 21M contentions out of > 27M acquisitions, and an average wait

Re: [PATCHv9 RFC 1/3] Break up monolithic iommu table/lock into finer graularity pools and lock

2015-04-05 Thread Sowmini Varadhan
On (04/05/15 22:26), Benjamin Herrenschmidt wrote: > > So you decided to keep the logic here that updates the hint instead of > just getting rid of need_flush alltogether ? > > Out of curiosity, what's the rationale ? Did you find a reason why > resetting the hint in those two cases (rather than

Re: [PATCHv9 RFC 1/3] Break up monolithic iommu table/lock into finer graularity pools and lock

2015-04-05 Thread Benjamin Herrenschmidt
On Sun, 2015-04-05 at 07:49 -0400, Sowmini Varadhan wrote: > + if (likely(pass == 0)) { > + /* First failure, rescan from the beginning. > */ > + pool->hint = pool->start; > + set_flush(iommu); > +

[PATCHv9 RFC 1/3] Break up monolithic iommu table/lock into finer graularity pools and lock

2015-04-05 Thread Sowmini Varadhan
Investigation of multithreaded iperf experiments on an ethernet interface show the iommu->lock as the hottest lock identified by lockstat, with something of the order of 21M contentions out of 27M acquisitions, and an average wait time of 26 us for the lock. This is not efficient. A more scalable