Messages in this thread | | | Date | Sun, 20 May 2007 13:42:57 +0200 | From | Tomasz Chmielewski <> | Subject | Re: [RFC] LZO1X de/compression support |
| |
Bill Rugolsky Jr. wrote:
>> I'm certainly missing something but what are the advantages of this >> code (over current gzip etc.), and what will be using it? > > Richard's patchset added it to the crypto library and wired it into > the JFFS2 file system. We recently started using LZO in a userland UDP > proxy to do stateless per-packet payload compression over a WAN link. > With ~1000 octet packets, our particular data stream sees 60% compression > with zlib, and 50% compression with (mini-)LZO, but LZO runs at ~5.6x > the speed of zlib. IIRC, that translates into > 700Mbps on the input > side on a 2GHZ Opteron, without any further tuning. > > Once LZO is in the kernel, I'd like to see it wired into IPComp. > Unfortunately, last I checked only the "deflate" algorithm had an > assigned compression parameter index (CPI), so one will have to use a > private index until an official one is assigned.
I also though of using LZO compression for some of the diskless nodes which use iSCSI over 100 Mbit or slower.
Certainly, a fast de/compression algorithm in the kernel could bring some new, innovative uses:
- there are talks about compressed filesystems (jffs2, reiser4, LogFS) - why no one thought about a compressed tmpfs (should be way easier than a compressed on-disk filesystem, as we don't have to care about data recovery in event of a failure)?
- using compression for networking (like Bill mentioned)
- compressed caching
- compressed suspend-to-disk images (should suspend/restore faster this way)
-- Tomasz Chmielewski http://wpkg.org
- 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/
| |