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.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel