From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: rmoser <mlmoser@comcast.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Re: Swap Compression
Date: Sat, 26 Apr 2003 11:17:47 +0200 [thread overview]
Message-ID: <20030426091747.GD23757@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <200304251848410590.00DEC185@smtp.comcast.net>
On Fri, 25 April 2003 18:48:41 -0400, rmoser wrote:
>
> Yeah, I had to mail it 3 times. Lst time I figured it out.
<more formal junk>
- Your mailer doesn't generate In-Reply-To: or References: Headers.
This breaks threading.
- It is usually more readable if you reply below the quoted text you
refer to.
- Most people prefer, if you reply to all. Not everyone here is
actually subscribed to the list.
- Feel free to ignore any of this, as long as the mail contains
interesting information. :)
</more formal junk>
> As for the performance hit, the original idea of that very tiny format was
> to pack 6502 programs into 4k of code. The expansion phase is very
> tight and very efficient, and on a ... anything... it will provide no problem.
> The swap-on-ram as long as it's not like 200 MB uncompressed SOR and
> 1 MB RAM will I think work great in the decompression phase.
>
> Compression will take a little overhead. I think if you use a boyer-moore
> fast string search algo for binary strings (yes you can do this), you can
> quickly compress the data. It may be like.. just a guess... 10-30 times
> more overhead than the decompression phase. So use it on at least a
> 10-30 mhz processor. If I ever write the code, it won't be kernel; just the
> compression/decompression program (userspace). Take the code and
> stuff it into the kernel if I do. I'll at the point of the algo coming in to
> existence make another estimate.
A userspace program would be just fine. Send it to me and I'll convert
it to the kernel, putting it somewhere under lib/.
Do you have any problems with a GPL license to your code (necessary
for kernel port)?
> The real power in this is Swap on RAM, but setting that as having precidence
> over swap on disk (normal swaps) would decrease disk swap usage by
> supplying more RAM in RAM. And of course swapping RAM to RAM is
> a lot faster. I'm looking at this for PDA's but yes I will be running this on
> my desktop the day we see it.
Swapping RAM to RAM sounds interesting, but also quite complicated. As
a first step, I would try to compress the swap data before going to
disk, that should be relatively simple to do.
("I would" means, I will if I find the time for it.)
> Well, I could work on the compression code, mebbe I can put the tarball up
> here. If I do I'd expect someone to add the code to swap to work with it--in
> kernel 2.4 at the very least (port it to dev kernel later!). As a separate module.
> We don't want code that could be mean in the real swap driver. :)
Right. But for 2.4, there is no swap driver, that you can simply
enable or disable. I hacked up a patch, but so far, disabling swap
eats ~100k of memory every second, so that clearly needs more work.
Jörn
--
Do not stop an army on its way home.
-- Sun Tzu
next prev parent reply other threads:[~2003-04-26 9:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-25 22:48 Re: Swap Compression rmoser
2003-04-26 9:17 ` Jörn Engel [this message]
[not found] ` <200304261148590300.00CE9372@smtp.comcast.net>
[not found] ` <20030426160920.GC21015@wohnheim.fh-wedel.de>
2003-04-26 23:41 ` Some code for " rmoser
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:22 ` William Lee Irwin III
2003-04-27 18:31 ` rmoser
2003-04-27 19:04 ` Jörn Engel
2003-04-27 19:57 ` Livio Baldini Soares
2003-04-27 20:24 ` rmoser
[not found] ` <200304271609460030.01FC8C2B@smtp.comcast.net>
2003-04-27 20:10 ` rmoser
2003-04-27 21:52 ` rmoser
2003-04-27 21:55 ` Re: Swap Compression -- Try 2 rmoser
2003-04-28 8:52 ` Swap Compression 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
-- strict thread matches above, loose matches on Subject: below --
2003-04-25 22:32 rmoser
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=20030426091747.GD23757@wohnheim.fh-wedel.de \
--to=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mlmoser@comcast.net \
/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).