Hi, On Fri, Jun 12, 2009 at 4:04 AM, John Mitchell <[email protected]>wrote:
> - what's the "sweet spot" for which compcache is most appropriate? > > I've read about using this for netbooks, where CPU is relatively free, it > has limited memory, and disk is at a premium. > Wherever RAM is a limiting factor and CPU is powerful enough (say, 1GHz) should be good use case for compcache. > > - for this sweet spot, what's the best test load, to measure performance? > How can this be made repeatable? > > The wiki mentions "load Firefox, OpenOffice, and 3 evince windows", but > that doesn't sound very repeatable. 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: http://en.wikipedia.org/wiki/Linux_Desktop_Testing_Project However, setting up this test, collecting and presenting numbers is a project in itself :) > The "scan" benchmark is very easy to use and is repeatable, but how > comparable is it to real-world information? > '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. > 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. > I observed similar results in my testing: compcache+backing_swap is generally faster than compcache alone. I could not explain this behaviour. > > > ** 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? > There are few things I do: - 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) - 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). - memlimit > 15% of RAM triggers oom-killer under heavy memory pressure. 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. http://www.flickr.com/photos/shavenwarthog/3618101530/ > > I could not understand what this graph shows. Thanks, Nitin
_______________________________________________ linux-mm-cc mailing list [email protected] http://lists.laptop.org/listinfo/linux-mm-cc
