On Thu, Jan 06, 2022 at 08:19:45PM -0400, Jason Gunthorpe wrote: > 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, Yes, that's exactly what I was thinking. > 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.. Ok, I can think more about this. > 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.. Sorry, comparison between what? I can take a look at iommufd tomorrow though and see if your comment makes more sense.
