All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nitin Gupta <ngupta@vflare.org>
To: Alexander Graf <agraf@suse.de>
Cc: virtualization@lists.linux-foundation.org,
	KVM development list <kvm@vger.kernel.org>
Subject: Re: [RFC] GSoC 2010: Memory Compression for Virtualized Environments
Date: Sat, 27 Mar 2010 15:17:02 +0530	[thread overview]
Message-ID: <4BADD416.5080807@vflare.org> (raw)
In-Reply-To: <9583F974-0EA0-40E2-9285-C04ECA395FC1@suse.de>

On 03/27/2010 02:31 PM, Alexander Graf wrote:
> 
> On 27.03.2010, at 08:38, Nitin Gupta wrote:
> 
<snip>

>> So, this GSoC project aims to provide a new approach for achieving memory
>> compression that solves all above issues: cleanly hook into reclaim path
>> directly, providing both swap and pagecache compression, avoiding all block I/O
>> overhead.
>>
>> Project motivation, design and implementation details are present in this
>> document:
>> www.scribd.com/doc/28713197/Memory-Compression-for-Virtualized-Environments
> 
> Very interesting project.
> 
> I'm not 100% sure it's a good idea to waste CPU time on page cache compression, but then again I guess with 64-core systems coming up CPU power is a lot cheaper than I/O. You should definitely keep NUMA in mind while doing this though. The target systems for this certainly aren't single node systems ;-).
> 

The target is certainly large scale systems. For 64-bit etc. crazy machines it might
be worth to even dedicate 1 or 2 cores for de/compression (though not necessary).
Even for desktops, 4 cores are now so common.

Then comes embedded, where other issues also come into picture -- slow random writes
on flash cards, wear-leveling issues, power to de/compress vs writing to flash etc.

I highlighted virtualization since large scale systems (and virtualization workload) are
easily justifiable for this feature :)

> Another thing that I realized while reading through this is that I'm missing the virtualization link. You do explain it in the introduction, but I certainly fail to see why this should be limited to virtualization. It'd improve swapping penalty in general.
> 

It is not limited to virtualization case and it does improve I/O penalty in non-virtualized case too
(as shown by compcache work). I highlighted virtualization only because its looks like an important
use case and benefits of memory compression are yet to be explored in this area.


On a side note: another project proposal I'm going to submit is:
 "Virtual Co-processor: Flexible and Scalable Virtual Machines"
you can see draft of the paper here:
http://www.scribd.com/doc/23978468/Virtual-Co-processors-Flexible-and-Scalable-Virtual-Machines



> Either way, I'm eager to see this get accepted :-).
> 

And I'm eager to start work on this :)


Thanks for your comments.
Nitin

  parent reply	other threads:[~2010-03-27  9:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-27  7:38 [RFC] GSoC 2010: Memory Compression for Virtualized Environments Nitin Gupta
2010-03-27  9:01 ` Alexander Graf
2010-03-27  9:47   ` Nitin Gupta
2010-03-27  9:47   ` Nitin Gupta [this message]
2010-03-27  9:01 ` Alexander Graf
  -- strict thread matches above, loose matches on Subject: below --
2010-03-27  7:38 Nitin Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BADD416.5080807@vflare.org \
    --to=ngupta@vflare.org \
    --cc=agraf@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.