linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: rmoser <mlmoser@comcast.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Swap Compression
Date: Tue, 29 Apr 2003 16:40:37 -0400	[thread overview]
Message-ID: <200304291640370180.04AB5D50@smtp.comcast.net> (raw)
In-Reply-To: <3EAEDB7C.9080101@techsource.com>

*********** REPLY SEPARATOR ***********

On 4/29/2003 at 3:39 PM Timothy Miller wrote:

>
>
>Con Kolivas wrote:
>
>On Tue, 29 Apr 2003 07:35, Timothy Miller wrote:
>
>The work that Rodrigo De Castro did on compressed caching
>(linuxcompressed.sf.net) included a minilzo algorithm which I used by
>default
>in the -ck patch addon as it performed the best for all the reasons you
>mention. Why not look at that lzo code for adoption.
>Some time before rmoser started HIS discussion on compressed swap, I
>started a discussion on the same topic.  Out of that discussion came
>mention of an existing project which did EXACTLY what I was proposing.
>That made me happy.  For some reason rmoser wants to start from scratch.
>He can do that if he wants.  I had only hoped that my earlier mention of
>it would spark interest in taking the existing implementation and adding
>it to the mainline kernel, after some incompatbilities were dealt with.
>Unfortunately, I don't have the time to engage directly in that particular
>aspect the kernel development
>

I want to start from scratch because I am trying a different angle, and I don't understand
fully current projects on it.  I am not trying to discredit anyone.  In fact, I would hope that
the existing implimentation (different as it is) would manage to get itself in as well.
Remember, modularity is all about options. Options aren't just "Do you want this or
that?", but also "How do you want this or that done?"  Plus, I am not compressing the
page cache, assuming I understand what this means.  AFAIK (from others' help), the
page cache is a cached copy of pages that have gone to the swap recently, or been
pulled off recently.  I am not touching that.

Other things (not brought up by me) include making a central compression library for the
kernel (modular, i.e. modprobe zlib and such) (Jorn's idea).  That is something that I think
would be essential for swap compression; why should one module horde all the compression
algo's?

--Bluefox



  reply	other threads:[~2003-04-29 20:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-29 20:07 Swap Compression Timothy Miller
2003-04-29 20:40 ` rmoser [this message]
2003-04-29 21:14   ` John Bradford
2003-04-30  0:59     ` rmoser
2003-04-30  2:48       ` Con Kolivas
2003-04-30 12:59         ` Jörn Engel
2003-04-30 19:18           ` rmoser
2003-05-01 22:07           ` rmoser
2003-05-02  2:46             ` jw schultz
  -- strict thread matches above, loose matches on Subject: below --
2003-05-09  3:21 Perez-Gonzalez, Inaky
2003-05-08  3:17 Perez-Gonzalez, Inaky
2003-05-08  8:07 ` Jörn Engel
2003-04-25 22:48 rmoser
2003-04-26  9:17 ` Jörn Engel
     [not found]   ` <200304261148590300.00CE9372@smtp.comcast.net>
     [not found]     ` <20030426160920.GC21015@wohnheim.fh-wedel.de>
2003-04-27  2:24       ` rmoser
2003-04-27  9:04         ` Jörn Engel
2003-04-27 17:24           ` rmoser
2003-04-27 17:51             ` Jörn Engel
2003-04-27 18:31               ` rmoser
2003-04-27 19:04                 ` Jörn Engel
2003-04-28  8:52                   ` Eric W. Biederman
2003-04-28 10:26                     ` Jörn Engel
     [not found]                 ` <3EAE8899.2010208@techsource.com>
     [not found]                   ` <200304291521120230.0462A551@smtp.comcast.net>
2003-04-29 19:21                     ` rmoser
     [not found]         ` <3EADAA5D.1090408@techsource.com>
     [not found]           ` <200304282258310030.00DED562@smtp.comcast.net>
2003-04-29  2:58             ` rmoser
2003-04-25 22:32 rmoser
2003-04-28 21:35 ` Timothy Miller
2003-04-29  0:43   ` Con Kolivas
     [not found] <200304251640110420.0069172B@smtp.comcast.net>
2003-04-25 20:48 ` rmoser
2003-04-25 21:14   ` Jörn Engel
2003-04-25 21:17   ` John Bradford

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=200304291640370180.04AB5D50@smtp.comcast.net \
    --to=mlmoser@comcast.net \
    --cc=linux-kernel@vger.kernel.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 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).