All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nitin Gupta <nitingupta910@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: penberg@cs.helsinki.fi, cl@linux-foundation.org, edt@aei.ca,
	linux-mm-cc@laptop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] compressed in-memory swapping take5
Date: Thu, 02 Apr 2009 05:32:45 +0530	[thread overview]
Message-ID: <49D400A5.20901@vflare.org> (raw)
In-Reply-To: <20090401155743.685e2c1e.akpm@linux-foundation.org>

Hi Andrew,

Thanks for your reply. My comments inline.

Andrew Morton wrote:

>>   - Links to more performance numbers, use cases can be found at:
>> http://lkml.org/lkml/2009/3/17/116
> 
> The sole, whole, entire point of this patchset is performance.  Yet
> after chasing a few scruffy links, the only data we have to justify
> merging _any_ of this stuff is, and I quote,
> 
>  - 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.
> 
> that isn't very compelling!
> 
> So would it be possible for you to come up with some more concrete
> testing results to help convince us that we should make this change to
> Linux?  And include them front-and-centre in the changelog, and
> maintain it?
>

Fair enough. I will get these numbers and include them in changelog itself.
Probably by next kernel release.

> We would also be interested in seeing the performance _loss_ from these
> patches.  There must be some cost somewhere.  Find a worstish-case test
> case and run it and include its results in the changelog too, so we
> better understand the tradeoffs involved here.
> 

Sure. I will get these too.

> 
> I'm really reluctant to go and merge a complete new memory allocator
> just on behalf of an obscure driver.  Oh well, perhaps hiding it down
> in drivers/block was the right thing to do.


Justification for this custom allocator is present in xvmalloc changelog
itself. It gives reason for not using SLUB and SLOB. During review
cycle, I never got any arguments against that justification.

For possible inclusion in Linux, I will hide it in drivers/block/ramzswap
and rename interfaces to make sure that no-one else can use it.

> 
> As the patchset adds five tightly-related files, perhaps it should all
> live in drivers/block/rmazswap/?
> 
> 

Ok, no problem.


Thanks for reply.
Nitin


  reply	other threads:[~2009-04-02  0:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-30 14:48 [PATCH 0/3] compressed in-memory swapping take5 Nitin Gupta
2009-03-30 14:50 ` [PATCH 1/3] xvmalloc memory allocator Nitin Gupta
2009-03-30 14:52 ` [PATCH 2/3] ramzswap virtual block device Nitin Gupta
2009-03-30 14:54 ` [PATCH 3/3] ramzswap documentation Nitin Gupta
2009-04-01 22:57 ` [PATCH 0/3] compressed in-memory swapping take5 Andrew Morton
2009-04-02  0:02   ` Nitin Gupta [this message]
2009-04-02  2:09     ` Christoph Lameter
2009-04-02  3:32       ` 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=49D400A5.20901@vflare.org \
    --to=nitingupta910@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=edt@aei.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm-cc@laptop.org \
    --cc=ngupta@vflare.org \
    --cc=penberg@cs.helsinki.fi \
    /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.