02:42 <robclark> bbrezillon, robmur01: one thought.. on the reclaim/evict side we also need to be able to unmap buffers.. in the reclaim path itself.. it is an operation that can fail but it is also a situation where having a pool of avail pages for pgtable updates would probably be useful (since it is better to keep around a few spare pages for pgtable than fail to unmap a much larger gem obj)

02:43 <robclark> (also, general thought about VM_BIND.. I think we want that but also a concept of an active-set.. VM_BIND being about the vm but active-set about the currently needed buffers within the vm.. and ideally both exposed as vk extension)

02:46 <robclark> I think extension of the VM_BIND idea with some sort of a way for a submit to reference 1 (or more?) active sets would resolve my concerns about the approach for an eventual similar thing for msm ;-)

16:03 <bbrezillon> robclark: you're talking about partial unmaps requiring an extra level in the page table tree?

16:05 <robclark> yeah, if a map splits a huge page

16:05 <robclark> s/map/unmap/

16:11 <bbrezillon> if the unmaps in the reclaim path is partial, does that mean you're partially unmapping the GEM object (and thus partially reclaiming its memory)? Or are you assuming that 2 GEMs can be assigned physically contiguous memory and the VM code would transparently merge the their VMA mappings if they're also virtually contiguous and have the same permissions?

16:28 <bbrezillon> robclark: if we keep GEM object mappings isolated (no transparent merging), and assume we always reclaim all pages of the GEM, we shouldn't have partial unmaps in the reclaim path. But maybe I'm missing something here.

16:37 <robclark> bbrezillon: the latter.. reclaim would always unmap full GEM obj, but it could just happen to form a huge(er) page with another obj

16:38 <robclark> yeah, I guess if you avoid merging it wouldn't be a problem, I think.. at cost of more TLB pressure

17:01 <bbrezillon> just curious how often you think we'd end up in this situation, given we don't control the physical pages we bind to GEMs (maybe you do). I can see how merging virtually contiguous mappings pointing to same GEM can be useful, but I wonder if it's worth optimizing the other case.

17:44 <robclark> not sure in practice.. but I guess you'll typically be allocating a bunch of buffers at once and also allocating iova in the same order..

17:45 <robclark> But I guess we have to solve this problem somehow for the map path..

17:50 <bbrezillon> sure

18:02 <robclark> bbrezillon, I guess one option is for driver to calc # of pages assuming no merging with other allocations and having those in a pre-alloc pool would be the way forward.. that seems straightforward to calculate and guarantees there are always enough pages avail to unmap

18:03 <robclark> might mean we have a few extra pages laying around if merging does happen but it would be no worse than disabling merging