[Spice-devel] UMS memory management

[Dave Airlie]

>
> 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.

Dave.