Hi Richard,
Thanks for these perf. figures!
On 5/25/07, Richard Purdie <[email protected]> wrote:
On Thu, 2007-05-24 at 11:50 -0700, Andrew Morton wrote:
> On Thu, 24 May 2007 18:15:17 +0100
> Michael-Luke Jones <[email protected]> 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.
Ok. Let's drop unsafe version. This will also do away will that Makefile debris.
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.
I suspect this is mainly due to replacement of COPY4() and open coded
byte-by-byte copying with memcpy() calls. I will rollback these
particular changes, remove unsafe version and will see again. I have
retained all other code as-is.
I will also try adding benchmarking code to my (GPL) 'compress-test'
module (same which I sent to Bret). Though it's pretty basic module
but should be sufficient to give required perf. figures.
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,
Nitin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
