[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4cefeab80705280903t6b2bb687g4eb1d9de2717f6ec@mail.gmail.com>
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/
Powered by blists - more mailing lists