On Wed, Apr 25, 2018 at 12:26:58PM -0400, Emilio G. Cota wrote: > On Wed, Apr 25, 2018 at 12:51:22 +0800, Peter Xu wrote: > > Add a per-iommu big lock to protect IOMMU status. Currently the only > > thing to be protected is the IOTLB cache, since that can be accessed > > even without BQL, e.g., in IO dataplane. > > Is the added lock going to protect anything else beyond a g_hash_table?
It's only for that now. Maybe there can be other candidates. > If not, did you consider using qht instead of the lock + hash table? > It would give you lockless lookups as well as scalable updates. Thanks for pointing that out. I didn't even know that we have such a nice hash there. :) Though for this series I would still prefer to keep the mutex way as is for now. Firstly, I'd better fix the problem first before considering performance - after all this series is not really persuing for performance but fixing holes. So we can have follow up works for QHT convertions. Meanwhile, IOTLB is a bit special in that it might really update more often than we thought, so I'm not really sure whether a RCU-based hash would bring better performance. This is even not considering the fact that Linux guest intel-iommu driver will do more tricks (like frequently flushing IOTLBs) to make the update much more than usual. But again, the suggestion is valid and it worths further investigations to make sure my understandings are correct. > > [Sorry if my question isn't relevant, I am not familiar with > this code and just briefly skimmed over this series. It's of course relevant. Thanks for your input! -- Peter Xu