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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox