Hi,<br><br><div class="gmail_quote">On Fri, Jun 12, 2009 at 4:04 AM, John Mitchell <span dir="ltr"><<a href="mailto:johnlmitchell@gmail.com">johnlmitchell@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- what's the "sweet spot" for which compcache is most appropriate?<br><br>I've read about using this for netbooks, where CPU is relatively free, it has limited memory, and disk is at a premium.<br>
</blockquote><div><br>Wherever RAM is a limiting factor and CPU is powerful enough (say, 1GHz) should be good use case for compcache.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>- for this sweet spot, what's the best test load, to measure performance? How can this be made repeatable?<br><br>The wiki mentions "load Firefox, OpenOffice, and 3 evince windows", but that doesn't sound very repeatable.</blockquote>
<div><br>I think such tests can be made repeatable. There must be some tools out there that can simulate user interaction with such applications - quick googling brought up this result:<br><a href="http://en.wikipedia.org/wiki/Linux_Desktop_Testing_Project">http://en.wikipedia.org/wiki/Linux_Desktop_Testing_Project</a><br>
However, setting up this test, collecting and presenting numbers is a project in itself :)<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The "scan" benchmark is very easy to use and is repeatable, but how comparable is it to real-world information?<br>
</blockquote><div><br><br>'scan' benchmark is just an approximation of workload where memory access happens to be linear and working set is greater than RAM. I cannot say if any real application exhibits such behaviour. This benchmark is primarily useful to stress compcache code (correctness, performance regressions etc.). I also find it useful when profiling the code as its an easy way to trigger swapping.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>For my tests, I ran three configurations of swap: traditional swap to disk, compcache only, and compcache with disk as backing store. The plot is linked below, and I'm happy to publish data & scripts if that is useful. I found that using compcache completed the workload quite a bit faster than just with disk-based swap, and compcache+backing store was faster. <br>
</blockquote><div><br><br>I observed similar results in my testing: compcache+backing_swap is generally faster than compcache alone. I could not explain this behaviour.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>
** How can I tune my system and load to best get results from compcache? For a VM, how much 1) RAM, 2) swap disk, and 3) how much compcache allocation? What's the test load?<br></blockquote><div><br><br>There are few things I do:<br>
- If compcache is almost full (reached its memlimit) and no. of hits to the cache is low (non-increasing value of NumReads in /proc/ramzswap) then unload and then reload compcache modules (unuse_compcache.sh; use_compcache.sh)<br>
- In above, note that simple swapoff /dev/ramzswap0 will not release memory currently allocated for compressed pages. You must do swapoff and then unload the ramzswap module (which is what unuse script does).<br> - memlimit > 15% of RAM triggers oom-killer under heavy memory pressure.<br>
<br>Ideally, above should be done automatically by compcache: dynamically adjust memlimit based on hit ratio, run-time defragmentation, moving unused compressed pages to backing swap etc. Though memory assigned to compressed pages grows/shrinks on demand, compcache is still fairly "static" in nature.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="http://www.flickr.com/photos/shavenwarthog/3618101530/" target="_blank">http://www.flickr.com/photos/shavenwarthog/3618101530/</a><br>
<br>
</blockquote><div><br>I could not understand what this graph shows.<br><br>Thanks,<br>Nitin<br><br></div></div>