On Tue, Oct 19, 2021 at 10:11:34AM -0700, Jacob Pan wrote: > Hi Jason, > > On Tue, 19 Oct 2021 13:57:47 -0300, Jason Gunthorpe <j...@nvidia.com> wrote: > > > On Tue, Oct 19, 2021 at 09:57:34AM -0700, Jacob Pan wrote: > > > Hi Jason, > > > > > > On Fri, 15 Oct 2021 08:18:07 -0300, Jason Gunthorpe <j...@nvidia.com> > > > wrote: > > > > On Fri, Oct 15, 2021 at 09:18:06AM +0000, Liu, Yi L wrote: > > > > > > > > > > Acquire from the xarray is > > > > > > rcu_lock() > > > > > > ioas = xa_load() > > > > > > if (ioas) > > > > > > if (down_read_trylock(&ioas->destroying_lock)) > > > > > > > > > > all good suggestions, will refine accordingly. Here destroying_lock > > > > > is a rw_semaphore. right? Since down_read_trylock() accepts a > > > > > rwsem. > > > > > > > > Yes, you probably need a sleeping lock > > > > > > > I am not following why we want a sleeping lock inside RCU protected > > > section? > > > > trylock is not sleeping > Of course, thanks for clarifying. > > > > For ioas, do we really care about the stale data to choose rw_lock vs > > > RCU? Destroying can be kfree_rcu? > > > > It needs a hard fence so things don't continue to use the IOS once it > > is destroyed. > I guess RCU can do that also perhaps can scale better?
RCU is not a fence, it is an eventual consistency mechanism and has very bad scaling if you don't use things like kfree_rcu Jason _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
