lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 02 Apr 2009 10:40:02 +1100
From:	Nigel Cunningham <ncunningham@...a.org.au>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Andreas Robinson <andr345@...il.com>,
	Alain Knaff <alain@...ff.lu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] lib: add fast lzo decompressor

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ