[cairo] [Patch] Limit the amount of shared memory that cairo-xcb uses

[Chris Wilson]

On Sun, 30 Jan 2011 18:21:06 +0100, Uli Schlachter <psychon at znc.in> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> today I was toying around with cairo-perf-trace. I made cairo-xlib and cairo-xcb
> not use the RENDER extension and wanted to see if there are any interesting
> performance differences with cairo-perf-trace (there aren't).
> 
> However, at first cairo-xcb ran into some CAIRO_STATUS_NO_MEMORY problems. It
> was uploading the rendered results via SHM, but didn't manage to free any of
> those allocations again. It managed to use 1.5 GiB of SHM before finally an
> allocation failed.
> 
> The attached patches make cairo limit itself to 16 MiB of shared memory per
> cairo_xcb_connection_t. The first patch implements the limit, then comes some
> cleanup and finally callers are modified to retry without SHM when SHM fails.
> 
> 16 MiB is a pretty arbitrary pick. If someone has any ideas why this would be
> too low / too high, feel free to mention them.

I am personally in favour of not using SHM by default. Enabling any amount
of SHM is likely to cause an issue somewhere and so needs to be managed by
the client.

In effect the only time where we use SHM effectively automatically is for
fallbacks. Where it is most useful is during pixel upload, and for that we
need client participation and something akin to
cairo_surface_create_similar_image() to allocate a SHM image (or fallback
appropriately) which can be filled by the client.

So in its current use, I don't believe it is very effective. For what I
wanted to use the framework for, allocating cairo_image_surface_t from SHM
segments, the client is directly responsible for the amount of allocation.
 
> If no one complains, I'll push this to master.

Make it 0 and add a cairo_xcb_connection_set_shm_transport_max() [or
somesuch].
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre