Hi,
This is kernel port of LZO1X-1 compressor and LZO1X decompressor (safe

version only).
--

If we get no perf. problems with this patch, then I beleive it is now

suitable to inclusion in mainline. Further cleanups and optimizations

can surely be done after that. It's still just ~500 LOC.

--
* Changes since 'take 4' (Full Changelog after this):

1) Again applied 1 cleanup (use cpu_to_le16): this was not causing slower perf.

2) Rolled back very minor cleanup: LZO_CHECK_MPOS_NON_DET macro is

back.   This is the last of cleanups that can cause different

assembler output than original. _Maybe_ this is cause for that ~9%

slowdown seen by Richard in compressor.
Can anyone do timing measurement in kernel space only. This will

eliminate all possible problems w.r.t usespace testing. I tried doing

the same using get_jiffies_64() across calls to compressor in the

'compress-test' module but this is giving same value when measured

just before and after calls to lzo1x_compress(). I don't know why.
If anyone can simply measure time across lzo1x_compress() and

lzo1x_decompress() calls in this compress-test module, then that will

give us proper perf. figures.
* Changelog vs. original LZO:

1) Used standard/kernel defined data types: (this eliminated _huge_

#ifdef chunks)

   lzo_bytep -> unsigned char *

   lzo_uint -> size_t

   lzo_xint -> size_t

   lzo_uint32p -> u32 *

   lzo_uintptr_t  -> unsigned long

2) Removed everything #ifdef'ed under COPY_DICT (this is not set for

LZO1X, so removed corres. parts).

3) Removed code #ifdef'ed for LZO1Y, LZO1Z, other variants.

4) Reformatted the code to match general kernel style.

5) The only code change: (as suggested by Andrey)

-#if defined(__LITTLE_ENDIAN)

-                             m_pos = op - 1;

-                             m_pos -= (*(const unsigned short *)ip) >> 2;

-#else

-                             m_pos = op - 1;

-                             m_pos -= (ip[0] >> 2) + (ip[1] << 6);

-#endif
+ m...
[ message continues ]

Before LZO code is sent to Linus, its selection in Kconfig should be

made orthogonal to the current zlib selection code.
This means:

1) Options in lib/Kconfig hidden (selectable by drivers as required)

2) Decompression and Compression support separated, as read-only

filesystems only need to build in decompression support.
Thanks,
Michael-Luke

-

LZO as hidden option has no practical sense. Although LZO should be

auto-selected when some dependent project is selected (e.g. reieser4)

- there should be separate patch for this. Mixing such changes with
Ok, I will do this.    I wonder if some difference in opinion in such

things can actually cause 10+ extra RFCs?
Cheers,

Nitin

-

No, LZO as a visible option makes no practical sense. Why would

anyone want to build LZO into a kernel when there are no in-kernel

users of the code?
In fact, all of the library code should probably go this way...
Michael-Luke Jones
-

Agreed. It should be a auto-selected hidden config option.

-

I wish I had time for this myself (I'll see if I can do this tonight) ... but

anyhow, the idea is quite simply this:
cycles_t start, end;

unsigned long long diff;
start = get_cycles();

/*

 * lzo1x_compress() or

 * lzo1x_decompress() or whatever

 * on large enough input size.

 */

end = get_cycles();
diff = end - start;
That is all there is to it.
Note that get_cycles() (on x86 boxes, at least) might not be usable

or trustworthy on SMP machines unless you ensure that your code

(including the start and end timing measurements) executes on the

same particular CPU.
You could also use something like this when pin-pointing the exact

cause of the performance loss you experienced when the code was

fully cleaned up initially (before you started rolling back some stuff).
Satyam

-