On Thu, Jan 06, 2022 at 02:05:27PM -0700, Alex Williamson wrote: > > > Yeah, good question. I tried doing it that way recently and it did > > > improve performance a bit, but I thought it wasn't enough of a gain to > > > justify how it overaccounted by the size of the entire pin. > > > > Why would it over account? > > We'd be guessing that the entire virtual address mapping counts against > locked memory limits, but it might include PFNMAP pages or pages that > are already account via the page pinning interface that mdev devices > use. At that point we're risking that the user isn't concurrently > doing something else that could fail as a result of pre-accounting and > fixup later schemes like this. Thanks, At least in iommufd I'm planning to keep the P2P ranges seperated from the normal page ranges. For user space compat we'd have to scan over the VA range looking for special VMAs. I expect in most cases there are few VMAs.. Computing the # pages pinned by mdevs requires a interval tree scan, in Daniel's target scenario the intervals will be empty so this costs nothing. At least it seems like it is not an insurmountable problem if it makes an appreciable difference.. After seeing Daniels's patches I've been wondering if the pin step in iommufd's draft could be parallized on a per-map basis without too much trouble. It might give Daniel a way to do a quick approach comparison.. Jason
