From: "Scott F. H. Kaplan" <sfkaplan@cs.amherst.edu>
To: Nitin Gupta <nitingupta.mail@gmail.com>
Cc: linux-mm@kvack.org
Subject: Re: why its dead now?
Date: Tue, 15 Nov 2005 09:27:02 -0500 [thread overview]
Message-ID: <20051115142702.GC31096@sirius.cs.amherst.edu> (raw)
In-Reply-To: <f68e01850511131035l3f0530aft6076f156d4f62171@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]
On Mon, Nov 14, 2005 at 12:05:58AM +0530, Nitin Gupta wrote:
> I'm wondering why this project is dead even when it showed great
> performance improvement when system is under memory pressure.
As he stated himself, the primary reason is that its primary
maintainer (Rodrigo) can no longer dedicate time to it.
> Are there any serious drawbacks to this?
As Rik pointed out, the main complication is adapting the compressed
cache size which can be trickier for some workloads than others. The
original, 2.4.x-line of linuxcompressed used a method of adaptivity
developed by those working on that project. It seemed to work for
many cases, but also could suffer performance degredation for some
workloads.
There is also the possibility of the adaptive method about which I
wrote in my dissertation and in a USENIX 1999 paper (see the
linuxcompressed page -- I believe it has links for these). This
adaptive method is much less likely to adapt badly for some workloads,
but it also requires more extensive changes to the way in which the
kernel stores referencing history.
For completely different purposes, we have a 2.4.x kernel that
maintains this history efficiently. If you (or anyone else) are
interested at some point in porting this reference-pattern-gathering
code forward to the 2.6.x line, then you could easily apply this other
adaptive mechanism to compressed caching.
> Do you think it will be of any use if ported to 2.6 kernel?
Sure. I think that the potential for compressed caching to ease the
performance degredation under memory pressure is only getting better
as hardware continues to evolve.
Scott
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2005-11-15 14:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-13 18:35 Nitin Gupta
2005-11-14 19:58 ` Rodrigo S de Castro
2005-11-15 3:28 ` Rik van Riel
2005-11-15 14:27 ` Scott F. H. Kaplan [this message]
2005-11-19 23:30 ` Rik van Riel
2005-11-20 2:24 ` Scott F. H. Kaplan
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=20051115142702.GC31096@sirius.cs.amherst.edu \
--to=sfkaplan@cs.amherst.edu \
--cc=linux-mm@kvack.org \
--cc=nitingupta.mail@gmail.com \
/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