>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.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/