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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 May 2007 21:33:32 +0530
From:	"Nitin Gupta" <nitingupta910@...il.com>
To:	"Adrian Bunk" <bunk@...sta.de>
Cc:	"Daniel Hazelton" <dhazelton@...er.net>,
	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 5/28/07, Adrian Bunk <bunk@...sta.de> wrote:
> On Mon, May 28, 2007 at 08:36:44PM +0530, Nitin Gupta wrote:
> >...
> > So, before this change, it will be good if it gets merged in mainline
> > and tested, at least for correctness, on all supported achs. All the
> > while, we will have a good feeling that there is still a good scope
> > for perf improvement :)
>
> The correct order is:
> - create one version with all the optimizations you have in mind

Already done. One more optimization is regarding use of memcpy() in
place of COPY4() macros and open byte-by-byte copying. There are some
places where it's very hard to get it correct without adding
additional checks on various values which casues futher overhead by
iteslf - even then I could not get them correct so I decided not to go
with this particular optimization by myself.

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

Replied in earlier mail regarding this.

> - then get it tested in -mm
>

This is what I am looking for :)

> After these steps, you can start considering getting it into mainline.
>

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