Swap Compression
Yeah you did but I'm going into a bit more detail, and with a very tight algorithm. Heck the algo was originally designed based on another compression algorithm, but for a 6502 packer. I aimed at speed, simplicity, and minimal RAM usage (hint: it used 4k for the code AND the compressed data on a 6502, 336 bytes for code, and if I turn it into just a straight packer I can go under 200 bytes on the 6502).
Honestly, I just never looked. I look in my kernel. But still, the stuff I defined about swapon options, swap-on-ram, and how the compression works (yes, compressed without headers) is all the detail you need about it to go do it AFAIK. Preplanning should be done there--done meaning workable, not "the absolute best."
--Bluefox Icy
---- ORIGINAL MESSAGE ----
List: linux-kernel Subject: Re: Swap Compression From: John Bradford <john () grabjohn ! com> Date: 2003-04-25 21:17:11
[Download message RAW]
Quoted 1 line
Sorry if this is HTML mailed. I don't know how to control those settings
HTML mail is automatically filtered from LKML.
Quoted 1 line
COMPRESSED SWAP
We discussed this on the list quite recently, have a look at:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105018674018129&w=2
and:
http://linuxcompressed.sourceforge.net/
John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · rmoser
Yeah you did but I'm going into a bit more detail, and with a very tight algorithm. Heck the algo was originally designed based on another compression algorithm, but for a 6502 packer. I aimed at speed, simplicity, and minimal RAM usage (hint: it used 4k for the code AND the compressed data on a 6502, 336 bytes for code, and if I turn it into just a straight packer I can go under 200 bytes on the 6502).
Honestly, I just never looked. I look in my kernel. But still, the stuff I defined about swapon options, swap-on-ram, and how the compression works (yes, compressed without headers) is all the detail you need about it to go do it AFAIK. Preplanning should be done there--done meaning workable, not "the absolute best."
I think we might be able to deal with a somewhat more heavy-weight compression. Considering how much faster the compression is than the disk access, the better the compression, the better the performance.
Usually, if you have too much swapping, the CPU usage will drop, because things aren't getting done. That means we have plenty of head room to spend time compressing rather than waiting. The speed over-all would go up. Theoretically, we could run into a situation where the compression time dominates. In that case, it would be beneficial to have a tuning options which uses a less CPU-intensive compression algorithm.
Quoted 2 lines
Quoted 18 lines · Timothy Miller
Quoted 7 lines · rmoser
Yeah you did but I'm going into a bit more detail, and with a very tight algorithm. Heck the algo was originally designed based on another compression algorithm, but for a 6502 packer. I aimed at speed, simplicity, and minimal RAM usage (hint: it used 4k for the code AND the compressed data on a 6502, 336 bytes for code, and if I turn it into just a straight packer I can go under 200 bytes on the 6502).
Quoted 5 lines
Honestly, I just never looked. I look in my kernel. But still, the stuff I defined about swapon options, swap-on-ram, and how the compression works (yes, compressed without headers) is all the detail you need about it to go do it AFAIK. Preplanning should be done there--done meaning workable, not "the absolute best."
I think we might be able to deal with a somewhat more heavy-weight compression. Considering how much faster the compression is than the disk access, the better the compression, the better the performance.
Quoted 6 lines
Usually, if you have too much swapping, the CPU usage will drop, because things aren't getting done. That means we have plenty of head room to spend time compressing rather than waiting. The speed over-all would go up. Theoretically, we could run into a situation where the compression time dominates. In that case, it would be beneficial to have a tuning options which uses a less CPU-intensive compression algorithm.
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.
Con