> -----Original Message----- > From: Stefan Hajnoczi [mailto:stefa...@gmail.com] > Sent: Friday, July 08, 2011 12:07 AM > To: Shribman, Aidan > Cc: qemu-devel@nongnu.org; Anthony Liguori > Subject: Re: [PATCH v2] XBRLE page delta compression for live > migration of large memory apps > > > Out of interest, why did ARC not work well as the caching algorithm? > Did you try it out and measure its performance? >
ARC would be a good candidate for serving as the page cache (storing content previously sent pages) but due to potential legal issues in light of IBM filing for patent on the ARC algorithm on November 2003 (see http://www.varlena.com/GeneralBits/96.php) I presume best if we refrain from using ARC in QEMU until situation is fully cleared. There are other fast O(1) compute time cache candidates such as 2Q, LIRS (which are not susceptible to memory scans as LRU is) but for now so as to keep things simple I have used for PATCH v3 a fully associative LRU cache replacing the 2-way cache used in PATCH v2. Obviously the fully associative LRU is slower than the 2-way set associative cache but still orders of magnitude higher than required (as pages are 4k in size and above). Needless to say that LRU gives a much higher hit/lookup ratio that the 2-way set associative cache. 1-way LRU: exec-time 0.10 secs; rate 19.66 M iops; hit-ratio 0.0502 2-way LRU: exec-time 0.09 secs; rate 20.51 M iops; hit-ratio 0.0503 4-way LRU: exec-time 0.10 secs; rate 19.46 M iops; hit-ratio 0.1011 8-way LRU: exec-time 0.11 secs; rate 17.03 M iops; hit-ratio 0.1009 Full LRU: exec-time 0.15 secs; rate 12.89 M iops; hit-ratio 0.1011 Aidan
