> > Did you run any performance tests to see if adding the extra > > spinlock (as the native SWIOTLB already has its own lock) and handling > > of the tree is affecting it?
.. bla bla.. > I haven't done any measurements but consider that the spin_lock is > already only used to access the red-black tree that keeps track of > dma_addr -> phys_addr mappings. > So it's taken at setup time once, then every time we call > xen_bus_to_phys and the guest is an autotraslate guest. > If the guest is not autotraslate there are no additional locks. > > That makes me realize that we don't need any spin_locks at all: there > are no risks of concurrent accesses and modifications of the tree > because there are no changes on the tree once it's setup at boot time. > We can get rid of the spin_lock entirely as concurrent read accesses on > the tree are obviously fine. Nice :-) I think that (and the goto) were the only concerns I had. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
