On Mon, 2015-03-23 at 12:54 -0400, Sowmini Varadhan wrote: > If it was only an optimization (i.e., removing it would not break > any functionality), and if this was done for older hardware, > and *if* we believe that the direction of most architectures is to > follow the sun4v/HV model, then, given that the sun4u code only uses 1 > arena pool anyway, one thought that I have for refactoring this > is the following: > > - Caller of iommu_tbl_range_alloc() can do the flush_all if they > see start <= end for the one single pool > - lose the other ->flush_all invocation (i.e., the one that is > done when iommu_area_alloc() fails for pass == 0, and we reset > start to 0 to roll-back) > > that would avoid the need for any iommu_tbl_ops in my patch-set. You must hold the lock until you do the flush, otherwise somebody else might allocate the not-yet-flushed areas and try to use them... kaboom. However if that's the only callback left, pass it as an argument. > But it would imply that you would still take the perf hit for the roll-back > if we failed the pass == 0 iteration through iommu_area_alloc(). > Perhaps this is an acceptable compromise in favor of cleaner code > (again, assuming that current/future archs will all follow the HV > based design). > > --Sowmini > -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
