Hi,
I just finished porting WKdm to kernel mode and have created a small
kernel module (attached) to test it separately from other things. The
module creates two /proc entries: /proc/compress & /proc/decompress.
Writing a file to /proc/compress compresses it and stores it in an
internal buffer and reading /proc/decompress shows the decompressed
output. Also, reading /proc/compress shows some stats (currently only
original and compressed size -- had trouble adding timer info). I
think this will be useful when porting other de/compression algorithms
too.
File to be written to /proc/compress should be <=3D4k (<4k files are
padded to make them 4k).
However, I have some doubts:
-- current WKdm uses Wk_word temp[1200] to store unpacked 10-bits i.e.
1 word (32/64-bit) per 10-bits. Why doesn't it use short(16-bit) to
store these 10-bit patterns in unpacked state? Although 2k memory
saving is insignificant but why waste it for free? Was it done for
some optimization purpose?
Currently, I've changed it to use short's as mentioned but can always
revert back if it was done purposefully.
-- WKdm_compress() does kmalloc()/kfree() pair thrice per call to this
function. Is it too much overhead? Should these temp buffers be made
global and use locking to serialize request for them (this isn't
performance friendly either)?
-- use of ceil() has been removed: had doubts with Rodrigo's
implementation which does:
ceil (double x) {
=09if (!(x - ((int) x)))
=09=09return ((unsigned int) x);
=09return ((unsigned int) (x + 1));
}
If kernel preempts in this ceil(), will value of 'x' remain valid
(kernel does not save and restore the floating point processor's
state) ?
Now, I'll try actually compressing pages with WKdm and then port other
algorithms like WK4x4 and LZO (copy-paste from Rodrigo's patch :) when
use of WKdm in cc-patch goes stable.
Cheers,
Nitin
|
