linux-kernel - Re: [RFC] LZO de/compression support

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:	Sat, 26 May 2007 11:28:45 +0100
From:	Richard Purdie <richard@...nedhand.com>
To:	Nitin Gupta <nitingupta910@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-mm-cc@...top.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Satyam Sharma <satyam.sharma@...il.com>,
	Andrey Panin <pazke@...pac.ru>, Bret Towe <magnade@...il.com>,
	Michael-Luke Jones <mlj28@....ac.uk>
Subject: Re: [RFC] LZO de/compression support - take 4

Hi Nitin,

On Fri, 2007-05-25 at 18:27 +0530, Nitin Gupta wrote:
> On 5/25/07, Richard Purdie <richard@...nedhand.com> wrote:
> > On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
> > > Richard, can you please provide perf. results for this patch also?
> > > Also, can you please mail back latest version of your LZO patch? In
> > > meantime, I will try to include benchmarking support to the
> > > 'compress-test' module.
> >
> > This version is 15% slower at decompression and about equal on
> > compression.
> >
> 
> If you don't mind, can you please try patch attached now? I have now
> also rolled back that cpu_to_le16() change as Satyam suggested. I see
> no other reason for this perf. loss as I made no other change!
> 
> Also, can you please verify if you are comparing your _safe_ version
> with this patch? This patch does not include unsafe version and the
> safe one is simply called lzo1x_decompress().

I've been looking at my benchmark figures and I think I've found why the
figures for my version were different to yours. Its not your code which
is at fault, its the way it was hooked into the benchmarking program.
The compiler was inlining some parts which it shouldn't have been
allowed to do, sorry :-/.

With that issue corrected, decompression is the same speed however
compression is showing about a 9% performance loss compared to my kernel
patch.

I did some diffs of the assembler outputted by our two versions (mine
matches minilzo). For decompression the output is effectively identical.
For compression, there are significant differences. If I add a noinline
attribute to lzo1x_compress_worker, that removes a lot of them (and
boosts speed a bit) but there are still differences. Ideally, I'd like
to understand why.

Regards,

Richard

-
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/