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:	Tue, 29 May 2007 17:33:55 +0530
From:	"Nitin Gupta" <nitingupta910@...il.com>
To:	"Adrian Bunk" <bunk@...sta.de>
Cc:	"Michael-Luke Jones" <mlj28@....ac.uk>,
	"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>
Subject: Re: [RFC] LZO de/compression support - take 6

On 5/29/07, Adrian Bunk <bunk@...sta.de> wrote:
> On Tue, May 29, 2007 at 09:08:27AM +0100, Michael-Luke Jones wrote:
> > On 28 May 2007, at 18:11, Adrian Bunk wrote:
> >
> >> I have not seen any explanations:
> >> - Why did the upstream author write the code that way?
> >
> > Apparently due to his requirement for extreme portability. The original
> > code was designed to work on everything from 16-bit DOS through CRAY
> > supercomputers through Windows, Unices and Linux.
>
> Sure, this could be the reason in some or all cases.
>
> The upstream author knows the code best, and discussing such issues with
> him will in many cases be a win:
>
> It could be that there was in some cases no good reason, and the
> upstream code that gets used by many other projects could become faster.
>
> Or there was a good reason that applies also to the in-kernel version
> and a change breaks some corner case.
>

I have mailed the author with detailed changelog - waiting for reply.

> > The author has stated on the thread that it's a good idea to remove
> > unnecessary ifdefs when porting the code into the kernel, given that the
> > portability requirements are obviously no longer needed.
>
> "remove unnecessary ifdefs" implies "generated code is identical".
>
> That's quite different from "code is 10% faster".
>

Daniel made some changes to his testing code and now the perf gain is just 1.6%.

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