[Spice-devel] Questions about image cache (in server/red_worker.c)

[Yaniv Kaul]

On 05/19/2011 09:42 AM, Yaniv Kaul wrote:
> On 05/19/2011 09:18 AM, Yonit Halperin wrote:
>> Hi,
>> you are not looking at the right cache. THe right cache is 
>> red_client_shared_cache.h  (shared among multiple monitors; doesn't 
>> store images, only ids).
>> The cached you looked at is the cache of the canvas.
>>
>> Cheers,
>> Yonit.
>
> That still doesn't make any sense to me:
> - I'm looking at some kind of cache (the relevant function names are 
> image_cache_put and image_cache_get). If it's not an image cache then 
> someone made a poor choice of names for them.
> - Per the current code, the cache has a 1024 slots hash table, yet 
> only 2 items max. can fit into it. If it is caching for the canvas, 
> does it really need to cache only two items, and if that's so, is that 
> the right way to do it?! (btw, enlarging the 2 items limit higher 
> makes more items go there right away, so perhaps there is some sense 
> in having more there? Donno).
> - When using XP, I do see entries get into it, when using F15 I don't. 
> Not sure if canvas is something you'd see in X as well.
>
> I'll take a look at red_client_shared_cache.h . Already spotted a typo 
> there.
> Y.

OK, here are the results of looking at red_client_shared_cache.h:
1. I still can't see any images being cached when running the F15 guest. 
XP does show caching activity.
2. The cache is not efficient in some ways:
- a single ad in a web page can consume all of it (as each image of it 
is put into the cache, in my case, each took ~0.5MB). Same seems to 
happen with any fading object (menus, for example).
- Moreover, since this ad will be changed with a different ad, there's a 
good chance those images will never be seen again. I wonder if there's 
something that can be done about it.
- Lastly, since those images are all in the same location and since the 
hash that into which slot to put the images is quite weak, they are all 
put into the same slot, making the cache quite non-uniform in 
distribution. Probably less of an issue.
3. I see many cases where a cache item is being hit repeatedly - quite 
instant (didn't time it). A hover over a menu, for example - 4 hits. I 
suspect some update coalescing could have saved from even sending the 
2nd update and on to server (and the client?).
4. Are the images in the cache compressed? Since we are compressing them 
when sending to the client, it might as well keep them compressed in its 
memory. Probably would mitigate some of the issues above.


All in all, looks like in normal work, the cache isn't useful enough - 
it'll fill up too fast, and won't save enough on the bandwidth with some 
normal usage patterns.
Y.

>
>>
>> On 05/18/2011 10:54 AM, Yaniv Kaul wrote:
>>> I suspect the image caching in the server is not the greatest:
>>> 1. Using latest Fedora 15 and QXL driver, I don't see any image being
>>> cached - at all.
>>> 2. Using XP with latest QXL driver, I do see some caching activity, but
>>> I suspect:
>>> - the cache is limited to 2(!) items only (as IMAGE_CACHE_MAX_ITEMS 
>>> is 2)
>>> - even if we fix the above (so IMAGE_CACHE_MAX_ITEMS is
>>> 2*IMAGE_CACHE_HASH_SIZE for example) there will be, many times, slot
>>> collisions. May or may not be such a big deal, depends how much we
>>> really think we'll be caching.
>>> - we are not caching that many images anyway. I expected with the above
>>> change to have a lot more images cached. I suspect the driver does not
>>> send many images for caching to the server for some reason.
>>>
>>>
>>> All that I've done to gather the above is sprinkle some red_printf()'s
>>> after reading the code:
>>>
>>
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel