[Trac #28] Compressed caching to RAM

[Zarro Boogs per Child]

#28: Compressed caching to RAM
-------------------------+--------------------------------------------------
 Reporter:  jg           |        Owner:  blizzard
     Type:  enhancement  |       Status:  new     
 Priority:  high         |    Milestone:  final   
Component:  kernel       |   Resolution:          
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by bluefoxicy):

 Nitin has stated on [https://wiki.ubuntu.com/CompressedMemory]:

   "I will be glad to continue its development if provided funding
   by Ubuntu. In case of funding, I will make my best attempt to
   get it to mainline (which is the only possible way of keeping
   this project alive/meaningful). If you want any details on
   current implementation status and roadmap please contact me"

 I believe there is benefit to getting this into mainline; among
 these is a broadened base of further research into this particular
 application of
 compression algorithms and improved usage of those algorithms.
 I believe that initially this will be a win, but a small one;
 continued development will improve the state of the art and
 increase the win.

 Some limiting factors are the size of memory and the behavior
 of memory access.  You can't just make all but 64M of RAM a
 compressed cache without compression thrashing (i.e. CPU activity,
 performance drop).  You can probably get away with the top
 16-32MiB, but at 40% compression this will give you 6.4-12.8MiB
 added effective memory (5-10% increase).  Still, it's difficult
 to argue with what is effectively "free" (cheaper performance and hardware
 wise than swapping; better than running out of memory).

 I encourage you to look to the future.  The state of the art can
 only improve once this is polished and in mainline; and the OLPC
 will be revised into more powerful versions as feasible.  In the
 future 256MiB of RAM will be feasible at very low cost, and the
 area devoted to compression will increase, probably adaptively by
 then.  The effective gain of 5-10% would then be 12.8-25.6MiB,
 but the gains would likely be up around 10-20%.

-- 
Ticket URL: <http://dev.laptop.org/ticket/28#comment:2>
One Laptop Per Child <http://laptop.org/>