Re: [RFC] [-mm] Remove 'unsafe' LZO decompressor



On Thu, 2007-05-24 at 11:50 -0700, Andrew Morton wrote:
On Thu, 24 May 2007 18:15:17 +0100
Michael-Luke Jones <mlj28@xxxxxxxxx> wrote:

Attached is a patch which may be desirable for -mm. It applies
directly to 2.6.22-rc2-mm1.

The patch removes the 'unsafe' LZO decompression function, lowering
the size of the minilzo.c file by nearly 500 out of an original 1727
lines. It also removes references to the 'unsafe' decompression
function in the public LZO header and the EXPORT_SYMBOL_GPL declaration.
[...]
Comments / disagreement all welcome :)

This is obviously a highly desirable thing to do for a number of reasons.
But have we quantified the performance difference?

Ok, I've done some tests:

1. Comparing the safe and unsafe functions

For my minilzo kernel patch, the safe version showed a 7.2% performance
hit. For Nitin's patch, it showed a 3.2% performance hit (but see
below).

Could be a lot worse and I don't object to the removal of the unsafe
version.

2. Comparing Nitin's code with my minilzo based kernel patch.

My kernel patch is about 2.25 times faster at decompression (16725Kb/ms
vs 7399Kb/ms) and fractionally faster at compression (1434kb/ms vs
1490kb/ms). As things stand the performance of Nitin's patch is
therefore unacceptable as that is a significant decompression
performance loss.

These tests are on 32 bit Intel and in userspace but I've found them to
be a pretty good indicator of what happens in the real world and on
other architectures.
For simplicity I made these tests with some existing code I had around
but its licence is such I can't share it, much to my frustration.

Cheers,

Richard

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



Relevant Pages

  • Re: Wheres the bzip2 compressed linux-kernel patch?
    ... > decompression time. ... So you're suggesting that your algorithm is optimized for a ... algorithm that takes upwards of 3 seconds on a system that maxed out at 16 ... You're welcome to code up your own patch to do whatever you darn well please. ...
    (Linux-Kernel)
  • Re: Damn you, FEDEX! or Nikon D40 lost in Springfield, MO blackhole.
    ... the 2 mp Mavica he had been using with a Nikon D40. ... After shopping around, he got me to order one for him. ... The shipper had it insured, but from what I have read it could take weeks to sort this crap out. ... You may get your insurance from FedEx and a couple weeks later they find it and deliver it. ...
    (alt.photography)
  • Re: x86_64 : kernel initial decompression hangs on vmware
    ... it to work by applying your patch at http://lkml.org/lkml/2007/8/4/72. ... VT execution under VMware and KVM. ... This makes the boot decompression run under VT, ... /* Compute the decompressed kernel start address. ...
    (Linux-Kernel)
  • Re: [RFC] LZO de/compression support - take 3
    ... I'll give you a patch to change the resier4 code in -mm then (if ... Can we decide on a Final Unifiedversion of LZO port and then ... The compressed cache code might be one exception since it does the ... There might be other such cases too, so removing 'unsafe' ...
    (Linux-Kernel)
  • Re: Easy trick to reduce kernel footprint
    ... My not working patch is here: ... The decompression works correctly, i think the problem is the address ... Another minor problem of lzma is that you need slightly more memory than ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)