[Spice-devel] UMS memory management

[Yonit Halperin]

On 03/28/2013 01:19 AM, Dave Airlie wrote:
>>
>> Can you please explain how all this relates to Dave's work on the KMS? He
>> mentioned that he implemented paging there as well.
>
> Well we won't be using the KMS driver in RHEL6, so we need to improve
> the old UMS driver for that use case.
>
> Though I expect UMS eviction will hit the same problems I hit with
> KMS, drawables that never get released, until
> you poke OOM.
>
> I think the interfaces you suggested would work okay, ssp from my
> testing with cairo-perf traces we got some 14MB
> allocations, if we can't evict one of those for some reason you are
> pretty much locked out.
>
> The other problem is that surface create cmds are implicitly pinned
> while the surface is active, which can create some
> pretty brutal fragmentation in the non-surface RAM area. I ended up
> suballocating all the surface creates/destroys
> in their own area and pinning them in KMS land, brutal but the only
> way I could make it work. Best explained I suppose
> as you don't get surface create cmd in signalled in the release ring
> until after the surface destroy command is sent.
> So having infinite surfaces just means you are going to run out of
> non-surface command RAM after another while.
>
> I'm not really sure the amount of information that is stored in
> surface create command really justifies it being pinned,
> the server should probably duplicate it and release the cmd ring area
> for the create.
>
I think the only reason for keeping the create_command is migration: the 
qxl vm state stores all the create commands of the living surfaces, and 
replays them after migration.
Instead, we could have just copied the surface data, and turn the 
command to be with group_id=MEMSLOT_GROUP_HOST instead of 
MEMSLOT_GROUP_GUEST. This will allow us to release the surface_create 
command immediately after processing them.

So to summarize, the desired changes in spice/qemu are:
(1) flush the release ring at the end of QXL_IO_DESTROY_SURFACE_WAIT
(2) add a similar io for drawables (maybe using the release_info.id)
(3) release surface_create commands immediately after processing them
(4) Not limiting the surfaces identifiers

  Correct?

> Dave.
>