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

[Nai Xia]

Well, some changes to my 2nd case:

1.  Two page in process A were swapped out to ramzswap and became one
compessed page.
2.  This compressed page is swapped to hard disk.
3.  Process A is killed its vm is freed.
4.  the page slot in ramzswap is marked as free while the compressed
page still in hard disk
5.  Another two pages come and want be compressed to the just freed
ramzswap page slot.
6.  Page fault, hard disk swap in the obsolete compressed page.
7.  newly compressed data filled into the page frame.

I think it is better to alloc a brand new page than swap in the old one.
Am I right ?

Best Regards,
Nai

On Mon, Mar 31, 2008 at 8:29 PM,  <nai.xia at gmail.com> wrote:
> 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
>