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/
