> From: Greg KH [mailto:greg@xxxxxxxxx] > Cc: devel@xxxxxxxxxxxxxxxxxxxxxx; Nitin Gupta; Dan Magenheimer > Subject: Re: [RFC] Snappy compressor for Linux Kernel (specifically, > zram) > > On Sat, Apr 16, 2011 at 12:45:41AM +0300, Zeev Tarantov wrote: > > On Fri, Apr 15, 2011 at 05:21, Greg KH <greg@xxxxxxxxx> wrote: > > > Why is this needed to be added to the kernel? What does it provide > that > > > users or other parts of the kernel needs? > > > > It is functionally a general data compression tool that trades off > > compression ratio for speed. It is optimized for x86-64 and there > > achieves compression at 250MB/sec and decompression at 500MB/sec > > (YMMV*). This is a better mousetrap, that can and should replace LZO > > in every place where the kernel currently uses LZO. > > Like where? > > Have you done so and found it really to be faster and smaller? If so, > benchmarks and the numbers will be required for this to be accepted. > > You need to show a solid use case for why to switch to this code in > order to have it accepted. In particular, zram and zcache both operate on a page (4K) granularity, so it would be interesting to see ranges of performance vs compression of snappy vs LZO on a large test set of binary and text pages. I mean one page per test... I'm no expert but I believe some compression algorithms have a larger startup overhead so may not be as useful for compressing "smaller" (e.g. 4K) streams. Also zram and zcache benefit greatly from a good compression ratio to pack more compressed pages into physical pages. Better compression means more pages saved in RAM, which means fewer disk accesses. So the tradeoff of compression ratio vs CPU-cycles-to-compress is difficult to evaluate without real benchmarks and the results may be counterintuitive. Dan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
