Re: [PATCH 1/2] lib: add fast lzo decompressor

[Nigel Cunningham <ncunningham@crca.org.au>]

Hi.

On Wed, 2009-04-01 at 16:11 -0700, Arjan van de Ven wrote:
> H. Peter Anvin wrote:
> > Andreas Robinson wrote:
> >> Anyway, I assume it is maintainability rather than size you're concerned
> >> about here?
> > 
> > Right, of course.
> > 
> >> OTOH, the safe version is far from useless.
> >> I estimate (but haven't tested yet) that you would lose about 40 ms in
> >> the Eee test case. That is, the boot-time savings are reduced from 123
> >> to perhaps 85 ms which is still acceptable. It is certainly much less
> >> complicated than the alternatives, so if that's what you would prefer I
> >> can go that way.
> > 
> > I think if the cost is 40 ms once during boot on a slow platform, it's 
> > worth unifying the two codebases.  I am *not* saying that I don't think 
> > boot performance matters -- far be from it -- but I think this is 
> > probably worth the reliability and maintainability advantages of having 
> > a single piece of code if at all possible.
> > 
> > Of course, if you can figure out how to avoid that and still have the 
> > code clean, then that's another matter.
> > 
> > [Cc: Arjan, fast boot evangelizer. ;)]
> 
> as long as LZO is optional.... and it's documented somewhere to not use
> it if you want fast speed I'm totally fine.

Sorry to jump in with a tangential issue, but I just noticed the thread
and it reminded me of an issue :)

Should the lzo code used via cryptoapi (I believe it's the same stuff)
be SMP safe? I've tried to use it work TuxOnIce and get image corruption
(test kernel is 64 bit). The same code works fine if I tell it to use
LZF (which comes with TuxOnIce), no compression or, IIRC, work single
threaded.

Regards,

Nigel