RE: [lc-devel] WKdm to kernel mode

[Scott K. <sfk...@am...>]

 Nitin,

> -- 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=20
> short(16-bit) to store these 10-bit patterns in unpacked=20
> state? Although 2k memory saving is insignificant but why=20
> waste it for free? Was it done for some optimization purpose?

The goal was efficiency.  Some architectures don't handle half-words as
quickly as full words.  For the x86, there may be no difference.  I'd
handle this as an empirical issue:  Compile is using shorts and test the
speed; change in back to ints/longs and see if it's any faster.  If not,
keep it as 16-bit values.

> -- WKdm_compress() does kmalloc()/kfree() pair thrice per=20
> call to this function. Is it too much overhead? Should these=20
> temp buffers be made global and use locking to serialize=20
> request for them (this isn't performance friendly either)?

The original code, which ran only in user-land, did no heap allocating.
Given that the compressor will be called very frequently, it needs to be
fast.  If you can allocate these spaces statically or on the stack, then
do it and save the malloc/free operations.

> If kernel preempts in this ceil(), will value of 'x' remain=20
> valid (kernel does not save and restore the floating point processor's
> state) ?

The problem is worse than that:  Since the kernel does not preserve FP
registers, use of FP values in the kernel may clobber legitimate
user-land values.  You can't do that.  You have to change the use of
doubles to some kind of integer for kernel code.

Scott