[linux-mm-cc] First experience of compressed cache

[nai.xia at gmail.com]

Thank you for your reply, John!

On Mon, Mar 31, 2008 at 06:47:49PM +0800, John McCabe-Dansted wrote:
> Nitin Gupta isn't online at the moment, so I'll try to answer a couple
> of points.
> 
> On Mon, Mar 31, 2008 at 6:07 PM,  <nai.xia at gmail.com> wrote:
> >  2. Booted them with default loaded compcache (that means 25% of RAM was used as ramswap).
> 
> Actually it means that the ramzswap0 device is 25% of the size of ram.
> This means that up to 12.5% of ram will be used, assuming a 2:1
> compression ratio.

     I see :)

> 
> >  I get from the paper "Adaptive Compressed Caching: Design and Implementation"
> 
> I understand that compcache-0.3 is not adaptive, unfortunately.
> 
> >  that this method should suit to both hard swap backed cache and file cache,
> >  while it seems that the features are still not in your code.
> 
> I don't know what you mean by "hard swap backed cache". I understand
> that compcache-0.3 only compresses anonymous pages, not pages backed
> by the filesystem (i.e. pages in the "file cache")


   Oh, I mean the pages which are about to be swapped out to or swapped in 
   from real hard disk based swap ( maybe  I should say "swap cache" ? ). 
   Because I THINK ( I cannot proof it right now :)) some of the performance 
   loss in my initial experiment comes from the following (possible) case:
   1. anonymous pages are evicted to ramzswap0 because of ram pressure.
   2. ramzswap0 gets full but still ram pressure is high, so MM begins to push 
      pages to real hard disk swap.
   3. When choosing which page to evict, from the point of the MM, the newly
   compressed pages grasped by ramzswap0 are "young/new", so they are slow 
   to get out of the ram. While the fact is they may be the oldest pages, only
   in a compressed form. 
   4. So many younger pages are pushed to real hard disk I/O directly 
      WITHOUT compressed, while the real old pages still stay in ram(ramzswap0).
   
   And I can see another case where I/O is wasted if we do not touch the VM
   itself:
	When remove_mapping(), if the swap entry is in ramzswap0, and
	unfortunately, the corresponding ramzswap0 page was swapped out to 
	real hard disk. If the VM have no idea of this "stacked" swapping,
	then it will firstly swap it in from the hard disk and then remove 
	the ramzswap0 entry, instead of directly swap_free the hard disk entry.

   
   Maybe I am wrong,because I have not thoroughly read the code :). 
   This is my initial & naive feeling, I think I will read
   the code carefully. 

> 
> > will all that features planned on the roadmap of the version based on kernel
> > 2.6? (sorry, I did not find roadmap info in the project homepage)
> 
> I don't know Gupta's plans, but I understand that we want to keep the
> compcache smallish without the need for any invasive patches, so that
> it is easy to get into the official kernel. That being said, it seems
> like we could implement some form of adaptive memory use without
> needed invasive patches.

    My crazy little naive intuition tells me that MAYBE we will get much more if
    we can patch the core algorithms like page aging or swapping, etc.

    I think I can understand your points, my suggestion is just CRAZY, ha :)


> 
> > I am very much interested in this project, however I am still a kernel newbie.
> 
> Same here :)

Hey, Good to see you ~~

> 
> -- 
> John C. McCabe-Dansted
> PhD Student
> University of Western Australia