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
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
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
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);
> +
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