On 5/22/21 3:13 AM, Christian König wrote:
Hi Zack,
IIRC that was for the VMW_PL_GMR type, wasn't it?
As far as I have seen that backend was just giving out unique numbers and it
looked questionable that we allocated pages for that.
E.g. when you set that flag then for each allocation we also allocate a TTM tt
structure and a corresponding page.
Got ya. Yea, it's a little messy. I think it's correct. Those unique numbers
are just identifiers for the bo's but the actual memory for them is regular
system memory (e.g. we just tell our virtual hardware, here's some guest system
pages and here's a unique id that we'll be using the refer to them).
Tangentially this also relates to a small issue with the rework of the memory accounting
and removing the old page allocator. In the old page allocator we could specify what's
the limit of system memory that the allocator could use (via ttm_check_under_lowerlimit)
so the memory accounting that we've moved back to vmwgfx does nothing right now (well, it
"accounts" just doesn't act on the limit ;) ).
We could probably add a call to ttm_check_under_lowerlimit in our ttm_populate
callback (vmw_ttm_populate) but it is a little wacky. That's because in some
situations we do want to ignore the limit on system memory allocations, purpose
which we used to use ttm_operation_ctx::force_alloc for. I don't love designs
that are so driver specific so I'd prefer to avoid using force_alloc that is
only used internally by vmwgfx but I don't see a clean way of being able to put
a limit on system memory that our driver is using.
Just to explain, our virtual hardware is basically an integrated gpu nowadays,
so all the memory it allocates comes from system memory (with those unique
numbers to identify it) and, especially on vm's that have lower amount of ram,
we would like to limit how much of it will be used for graphics.
z
