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:	Mon, 28 May 2007 16:18:40 -0400
From:	Daniel Hazelton <dhazelton@...er.net>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Nitin Gupta <nitingupta910@...il.com>,
	lkml <linux-kernel@...r.kernel.org>, linux-mm-cc@...top.org,
	linuxcompressed-devel@...ts.sourceforge.net,
	Andrew Morton <akpm@...ux-foundation.org>,
	Richard Purdie <richard@...nedhand.com>,
	Bret Towe <magnade@...il.com>,
	Satyam Sharma <satyam.sharma@...il.com>
Subject: Re: [RFC] LZO de/compression support - take 6

On Monday 28 May 2007 13:11:15 Adrian Bunk wrote:
> On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote:
> > On 5/28/07, Adrian Bunk <bunk@...sta.de> wrote:
> >...
> >
> >> - then ensure that it works correctly on all architectures and
> >
> > Already tested on x86, amd64, ppc (by Bret). I do not have machines
> > from other archs available. Bret tested 'take 3' version but no
> > changes were introduced in further revisions that could affect
> > correctness - but still it will be good to have this version tested
> > too. Only with inclusion in -mm and testing by much wider user base
> > can make it to mainline (I suppose nobody uses -mm for production use
> > anyway).
> >
> >>   document why your version is that much faster than the original
> >>   version and why you know your optimizations have no side effects

With likely(), unlikely() and noinline *not* defined as NOP's performance 
drops:

10000 run averages:
'Tiny LZO':
        Combined: 84.9292 usec
        Compression: 42.4646 usec
        Decompression: 42.4646 usec
'miniLZO':
        Combined: 61.3548 usec
        Compression: 43.5648 usec
        Decompression: 17.79 usec

However, I'm worried that my testbed code - likely the Perl script that 
actually loops the test code and collects its output - is somehow faulting, 
as the way that the Compression and Decompression code have the exact same 
value.

I'm going to toss some debugging output in the script and see if I can spot 
the problem.

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