From: Minchan Kim <minchan.kim@gmail.com>
To: Nitin Gupta <ngupta@vflare.org>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
andreas.dilger@oracle.com, chris.mason@oracle.com,
viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
adilger@sun.com, tytso@mit.edu, mfasheh@suse.com,
joel.becker@oracle.com, matthew@wil.cx,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
ocfs2-devel@oss.oracle.com, linux-mm@kvack.org, jeremy@goop.org,
JBeulich@novell.com, kurt.hackel@oracle.com, npiggin@suse.de,
dave.mccracken@oracle.com, riel@redhat.com, avi@redhat.com,
konrad.wilk@oracle.com
Subject: Re: [PATCH V2 0/7] Cleancache (was Transcendent Memory): overview
Date: Fri, 4 Jun 2010 22:45:24 +0900 [thread overview]
Message-ID: <20100604134524.GD1879@barrios-desktop> (raw)
In-Reply-To: <4C08C931.3080306@vflare.org>
Hi, Nitin.
I am happy to hear you started this work.
On Fri, Jun 04, 2010 at 03:06:49PM +0530, Nitin Gupta wrote:
> On 06/03/2010 09:13 PM, Dan Magenheimer wrote:
> >> On 06/03/2010 10:23 AM, Andreas Dilger wrote:
> >>> On 2010-06-02, at 20:46, Nitin Gupta wrote:
> >>
> >>> I was thinking it would be quite clever to do compression in, say,
> >>> 64kB or 128kB chunks in a mapping (to get decent compression) and
> >>> then write these compressed chunks directly from the page cache
> >>> to disk in btrfs and/or a revived compressed ext4.
> >>
> >> Batching of pages to get good compression ratio seems doable.
> >
> > Is there evidence that batching a set of random individual 4K
> > pages will have a significantly better compression ratio than
> > compressing the pages separately? I certainly understand that
> > if the pages are from the same file, compression is likely to
> > be better, but pages evicted from the page cache (which is
> > the source for all cleancache_puts) are likely to be quite a
> > bit more random than that, aren't they?
> >
>
>
> Batching of pages from random files may not be so effective but
> it would be interesting to collect some data for this. Still,
> per-inode batching of pages seems doable and this should help
> us get over this problem.
1)
Please, consider system memory pressure case.
In such case, we have to release compressed cache pages.
Or it would be better to discard not-good-compression pages
when you compress it.
2)
This work is related to page reclaiming.
Page reclaiming is to make free memory.
But this work might free memory little than old.
I admit your concept is good in terms of I/O cost.
But we might discard more clean pages than old if you want to
do batching of pages for good compression.
3)
testcase.
As I mentioned, it could be good in terms of I/O cost.
But it could change system's behavior due to page consumption of backend.
so many page scanning/reclaiming could be happen.
It means hot pages can be discarded with this patch.
But it's a just guessing.
So we need number with testcase we can measure I/O and system
responsivness.
>
> Thanks,
> Nitin
--
Kind regards,
Minchan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-06-04 13:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100528173510.GA12166@ca-server1.us.oracle.com>
2010-06-02 6:03 ` [PATCH V2 0/7] Cleancache (was Transcendent Memory): overview Minchan Kim
2010-06-02 15:27 ` Dan Magenheimer
2010-06-02 16:38 ` Minchan Kim
2010-06-02 23:02 ` Dan Magenheimer
2010-06-03 2:46 ` Nitin Gupta
2010-06-03 4:53 ` Andreas Dilger
2010-06-03 6:25 ` Nitin Gupta
2010-06-03 15:43 ` Dan Magenheimer
2010-06-04 9:36 ` Nitin Gupta
2010-06-04 13:45 ` Minchan Kim [this message]
2010-06-02 13:00 ` Jamie Lokier
2010-06-02 15:35 ` Dan Magenheimer
2010-06-02 13:24 ` Christoph Hellwig
2010-06-02 16:07 ` Dan Magenheimer
2010-05-28 17:35 Dan Magenheimer
[not found] <20100528173510.GA12166@ca-server1.us.oracle.comAANLkTilV-4_QaNq5O0WSplDx1Oq7JvkgVrEiR1rgf1up@mail.gmail.com>
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=20100604134524.GD1879@barrios-desktop \
--to=minchan.kim@gmail.com \
--cc=JBeulich@novell.com \
--cc=adilger@sun.com \
--cc=akpm@linux-foundation.org \
--cc=andreas.dilger@oracle.com \
--cc=avi@redhat.com \
--cc=chris.mason@oracle.com \
--cc=dan.magenheimer@oracle.com \
--cc=dave.mccracken@oracle.com \
--cc=jeremy@goop.org \
--cc=joel.becker@oracle.com \
--cc=konrad.wilk@oracle.com \
--cc=kurt.hackel@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew@wil.cx \
--cc=mfasheh@suse.com \
--cc=ngupta@vflare.org \
--cc=npiggin@suse.de \
--cc=ocfs2-devel@oss.oracle.com \
--cc=riel@redhat.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).