On Tue, 29 Apr 2003 07:35, Timothy Miller wrote:
> rmoser wrote:
> >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.
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
-
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/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:31 EST