public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/3] compressed in-memory swapping take2
@ 2009-03-20 14:07 Nitin Gupta
  2009-03-20 14:10 ` [PATCH 1/3] compressed RAM block device Nitin Gupta
                   ` (2 more replies)
  0 siblings, 3 replies; 24+ messages in thread
From: Nitin Gupta @ 2009-03-20 14:07 UTC (permalink / raw)
  To: Pekka Enberg, Christoph Lameter; +Cc: linux-kernel

Hi,

It allows creating a RAM based block device which acts as swap disk.
Pages swapped to this device are compressed and stored in memory itself.
This is a big win over swapping to slow hard-disk which are typically used
as swap disk. For flash, these suffer from wear-leveling issues when used
as swap disk - so again its helpful. For swapless systems, it allows more
apps to run.

* Changelog: take2 vs initial revision:
xvmalloc changes:
  - Use Linux kernel coding sytle for xvmalloc
  - Collapse all individual flag test/set/get to generic {test_set_get}_flag
  - Added BLOCK_NEXT() macro to reach next contiguous block
  - Other minor cleanups - no functional changes
compcache block device code:
  - compcache core changes due to change in xvmalloc interface names

Links to performance numbers, use cases can be found in original thread:
http://lkml.org/lkml/2009/3/17/116

Thanks to Christoph and Pekka for feedback on initial revision.

Thanks,
Nitin

^ permalink raw reply	[flat|nested] 24+ messages in thread
* [PATCH 0/3]: compressed in-memory swapping
@ 2009-03-17 11:34 Nitin Gupta
  2009-03-17 11:36 ` [PATCH 1/3]: compressed RAM block device Nitin Gupta
  0 siblings, 1 reply; 24+ messages in thread
From: Nitin Gupta @ 2009-03-17 11:34 UTC (permalink / raw)
  To: linux-kernel

Hi,

Project home: http://code.google.com/p/compcache/

It allows creating a RAM based block device which acts as swap disk.
Pages swapped to this device are compressed and stored in memory itself.
This is a big win over swapping to slow hard-disk which are typically used
as swap disk. For flash, these suffer from wear-leveling issues when used
as swap disk - so again its helpful. For swapless systems, it allows more
apps to run.

Its now part of Ubuntu, ALT Linux and some other distros.

Some use cases:
  - Embedded Devices: Memory is scarce and adding more memory increases
    device cost. Also, flash storage suffers from wear-levelling issues.
  - Virtualization: For host/hypervisor, VM/guest memory is all anonymous
    memory. So, compcache can compress any part of guest. So we can host
    more VMs on same amount of memory.
  - Thinclients.

Testing/Performance:
  - Testing for use on Thinclients (contrib: Nai Xia):
     Details: http://code.google.com/p/compcache/wiki/LTSPPerf
     Summary: http://code.google.com/p/compcache/wiki/LTSPPerfSummary

     Summary: after the compcache was loaded:
         - The time of paging down one pdf page was reduced to 1/4~1/100
         - The time of switching from one firefox tab to another was reduced to 1/6
         - The capacity of kpdf was be increased from 2 pdf files to 11 pdf files.
         - The capacity of firefox was increased from 6 web pages to 15 web pages.

  - Testing on x86 and x64 VMs (256/512MB RAM, 1 VCPU, 512MB Swap):
    Started Fedora 10 and some "generic desktop" apps (KDE4, Firefox,
    filemanager, editors) - without compcache, system swapped heavily
    and very unresponsive. With compcache, very noticeable improvement
    in responsiveness.

  - Some reported running on PS3 systems though no performance stats
    available here.

Limitations:
  - Being a "swap disk" it can compress only anonymous memory. But as mentioned
    above, at hypervisor/host level, all guest memory is anonymous so any part
    of guest memory can be compressed.
  - Memory allocator used is not scalable at all (work in progress).
  - No run-time defragmentation, swapping of allocated memory - however,
    incompressible pages are forwarded to physical swap and can set limit
    on amount of memory used by compcache.

I do not claim performance gain for any arbitrary workload but as testing
shows, it certainly helps in some cases :)

Also note that this is a low risk change - it does not modify any part
of kernel. Its just an additional module. In case you find it hurting
performance, just unload this module and maybe use normal disk swap.

Any reviews/comments/suggestions are welcome.

Thanks,
Nitin

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2009-03-21 17:37 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-20 14:07 [PATCH 0/3] compressed in-memory swapping take2 Nitin Gupta
2009-03-20 14:10 ` [PATCH 1/3] compressed RAM block device Nitin Gupta
2009-03-20 14:12 ` [PATCH 2/3] xvmalloc memory allocator Nitin Gupta
2009-03-20 14:57   ` Christoph Lameter
2009-03-20 16:24     ` Nitin Gupta
2009-03-20 17:40       ` Christoph Lameter
2009-03-20 19:01         ` Pekka Enberg
2009-03-20 19:43           ` Nitin Gupta
2009-03-21 10:21             ` Andrew Morton
2009-03-21 12:12               ` Nitin Gupta
2009-03-21 12:24                 ` Andrew Morton
2009-03-21 13:14                   ` Nitin Gupta
2009-03-21 16:21                   ` Pekka Enberg
2009-03-21 17:36                     ` Nitin Gupta
2009-03-20 14:14 ` [PATCH 3/3] compcache documentation Nitin Gupta
2009-03-21 10:26   ` Andrew Morton
2009-03-21 12:31     ` Nitin Gupta
2009-03-21 12:55       ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2009-03-17 11:34 [PATCH 0/3]: compressed in-memory swapping Nitin Gupta
2009-03-17 11:36 ` [PATCH 1/3]: compressed RAM block device Nitin Gupta
2009-03-18 12:25   ` Nick Piggin
2009-03-18 12:38     ` Nitin Gupta
2009-03-18 12:49       ` Nick Piggin
2009-03-20 18:56   ` Pavel Machek
2009-03-20 19:53     ` Nitin Gupta

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox