[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4cefeab80705260421x2af3d65bi868a1cb37c6bd633@mail.gmail.com>
Date: Sat, 26 May 2007 16:51:17 +0530
From: "Nitin Gupta" <nitingupta910@...il.com>
To: "Richard Purdie" <richard@...nedhand.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 Richard,
On 5/26/07, Richard Purdie <richard@...nedhand.com> wrote:
>
> 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.
>
I will look more closely into compression code to see why you are
getting this perf. difference here.
Thanks for your tests.
- 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