On Monday 28 May 2007 05:46:59 Nitin Gupta wrote:
> On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Monday 28 May 2007 05:08:54 Nitin Gupta wrote:
> > > On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > > > On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
> > > > > On
On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
On Monday 28 May 2007 05:08:54 Nitin Gupta wrote:
> On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
> > > On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
New testbed based
On Monday 28 May 2007 05:08:54 Nitin Gupta wrote:
> On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
> > > On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
>
>
>
> > > As you mentioned in your mail, you are using
On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
> On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
>
> As you mentioned in your mail, you are using lzo1x_1_11_compress()
> which is slower than what I ported (which is same as
On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
> On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > Test code for this version (take 4) of the minimized LZO1X (from the
> > liblzo v2) is complete.
> >
> >
> > I don't see a significant slow-down comparing the complete liblzo2 to
> > this
On 5/28/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
Test code for this version (take 4) of the minimized LZO1X (from the liblzo
v2) is complete.
I don't see a significant slow-down comparing the complete liblzo2 to this
minimized code on my system (Pentium M 1.73GHz, 1GB Ram, Kubuntu Feisty
Test code for this version (take 4) of the minimized LZO1X (from the liblzo
v2) is complete.
I don't see a significant slow-down comparing the complete liblzo2 to this
minimized code on my system (Pentium M 1.73GHz, 1GB Ram, Kubuntu Feisty
(stock Kubuntu kernel)). Rather, I see the opposite.
Test code for this version (take 4) of the minimized LZO1X (from the liblzo
v2) is complete.
I don't see a significant slow-down comparing the complete liblzo2 to this
minimized code on my system (Pentium M 1.73GHz, 1GB Ram, Kubuntu Feisty
(stock Kubuntu kernel)). Rather, I see the opposite.
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
Test code for this version (take 4) of the minimized LZO1X (from the liblzo
v2) is complete.
I don't see a significant slow-down comparing the complete liblzo2 to this
minimized code on my system (Pentium M 1.73GHz, 1GB Ram, Kubuntu Feisty
On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
Test code for this version (take 4) of the minimized LZO1X (from the
liblzo v2) is complete.
I don't see a significant slow-down comparing the complete liblzo2 to
this minimized code
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
snip
As you mentioned in your mail, you are using lzo1x_1_11_compress()
which is slower than what I ported (which is same as what is
On Monday 28 May 2007 05:08:54 Nitin Gupta wrote:
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
snip
As you mentioned in your mail, you are using lzo1x_1_11_compress()
which
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
On Monday 28 May 2007 05:08:54 Nitin Gupta wrote:
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
New testbed based on minilzo
On Monday 28 May 2007 05:46:59 Nitin Gupta wrote:
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
On Monday 28 May 2007 05:08:54 Nitin Gupta wrote:
On 5/28/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
On Monday 28 May 2007 04:37:04 Nitin Gupta wrote:
On 5/28/07, Daniel Hazelton
btw - does in-kernel lzo scale on SMP systems ?
is it a matter of lzo builtin compression or a matter of the component using
in-kernel lzo compression ?
if i write/read data on reiser4 filesystem with lzo compression on - will
all CPUs being used ?
just curious here, because i remember
Hi Richard,
On 5/26/07, Richard Purdie <[EMAIL PROTECTED]> 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
Hi Nitin,
On Fri, 2007-05-25 at 18:27 +0530, Nitin Gupta wrote:
> On 5/25/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
> > > Richard, can you please provide perf. results for this patch also?
> > > Also, can you please mail back latest
Hi Nitin,
On Fri, 2007-05-25 at 18:27 +0530, Nitin Gupta wrote:
On 5/25/07, Richard Purdie [EMAIL PROTECTED] wrote:
On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
Richard, can you please provide perf. results for this patch also?
Also, can you please mail back latest version of
Hi Richard,
On 5/26/07, Richard Purdie [EMAIL PROTECTED] 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
btw - does in-kernel lzo scale on SMP systems ?
is it a matter of lzo builtin compression or a matter of the component using
in-kernel lzo compression ?
if i write/read data on reiser4 filesystem with lzo compression on - will
all CPUs being used ?
just curious here, because i remember
Hi Daniel,
On 5/26/07, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
On Friday 25 May 2007 12:55:21 Daniel Hazelton wrote:
> As to the performance - I can see absolutely no reason why the minimal
> version shouldn't perform the same (or better). The kernel codes memset and
> memcpy routines have
On Friday 25 May 2007 12:55:21 Daniel Hazelton wrote:
> As to the performance - I can see absolutely no reason why the minimal
> version shouldn't perform the same (or better). The kernel codes memset and
> memcpy routines have been heavily tested *and* optimized over the years and
> moving from
On Friday 25 May 2007 09:38:24 Richard Purdie wrote:
> > > I am however still strongly of the opinion that we should just use the
> > > version in -mm (which is my latest version).
> >
> > Right, if the difference is anything >10%, code cleanup does lose
> > its attractiveness.
>
> Agreed, and I
On Fri, 2007-05-25 at 18:07 +0530, Satyam Sharma wrote:
> On 5/25/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
> > > Richard, can you please provide perf. results for this patch also?
> > > Also, can you please mail back latest version of
Hi Nitin,
On Fri, 2007-05-25 at 18:27 +0530, Nitin Gupta wrote:
> On 5/25/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
> > > Richard, can you please provide perf. results for this patch also?
> > > Also, can you please mail back latest
Hi Richard,
On 5/25/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
> Richard, can you please provide perf. results for this patch also?
> Also, can you please mail back latest version of your LZO patch? In
> meantime, I will try to include
Hi Richard,
On 5/25/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
> Richard, can you please provide perf. results for this patch also?
> Also, can you please mail back latest version of your LZO patch? In
> meantime, I will try to include
On 5/25/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
Hi,
This is kernel port of LZO1X compressor and LZO1X decompressor (safe
version only).
* Changes since 'take 3' (Full Changelog after this):
1) Removed 'unsafe' decompressor - hence also do away with symlinks in
Makefiles.
Nice :-)
2)
On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
> Richard, can you please provide perf. results for this patch also?
> Also, can you please mail back latest version of your LZO patch? In
> meantime, I will try to include benchmarking support to the
> 'compress-test' module.
This version is
On 25 May 2007, at 12:45, Nitin Gupta wrote:
Hi,
This is kernel port of LZO1X compressor and LZO1X decompressor (safe
version only).
Hey there,
It's looking better now. Just wondering if you might want to separate
out the Kconfig options for lzo compress / decompress so that it's
Hi,
This is kernel port of LZO1X compressor and LZO1X decompressor (safe
version only).
* Changes since 'take 3' (Full Changelog after this):
1) Removed 'unsafe' decompressor - hence also do away with symlinks in
Makefiles.
2) Rolled back changes where I replaced COPY4 with memcpy() calls.
This
Hi,
This is kernel port of LZO1X compressor and LZO1X decompressor (safe
version only).
* Changes since 'take 3' (Full Changelog after this):
1) Removed 'unsafe' decompressor - hence also do away with symlinks in
Makefiles.
2) Rolled back changes where I replaced COPY4 with memcpy() calls.
This
On 25 May 2007, at 12:45, Nitin Gupta wrote:
Hi,
This is kernel port of LZO1X compressor and LZO1X decompressor (safe
version only).
Hey there,
It's looking better now. Just wondering if you might want to separate
out the Kconfig options for lzo compress / decompress so that it's
On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
Richard, can you please provide perf. results for this patch also?
Also, can you please mail back latest version of your LZO patch? In
meantime, I will try to include benchmarking support to the
'compress-test' module.
This version is 15%
On 5/25/07, Nitin Gupta [EMAIL PROTECTED] wrote:
Hi,
This is kernel port of LZO1X compressor and LZO1X decompressor (safe
version only).
* Changes since 'take 3' (Full Changelog after this):
1) Removed 'unsafe' decompressor - hence also do away with symlinks in
Makefiles.
Nice :-)
2)
Hi Richard,
On 5/25/07, Richard Purdie [EMAIL PROTECTED] wrote:
On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
Richard, can you please provide perf. results for this patch also?
Also, can you please mail back latest version of your LZO patch? In
meantime, I will try to include
Hi Richard,
On 5/25/07, Richard Purdie [EMAIL PROTECTED] wrote:
On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
Richard, can you please provide perf. results for this patch also?
Also, can you please mail back latest version of your LZO patch? In
meantime, I will try to include
Hi Nitin,
On Fri, 2007-05-25 at 18:27 +0530, Nitin Gupta wrote:
On 5/25/07, Richard Purdie [EMAIL PROTECTED] wrote:
On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
Richard, can you please provide perf. results for this patch also?
Also, can you please mail back latest version of
On Fri, 2007-05-25 at 18:07 +0530, Satyam Sharma wrote:
On 5/25/07, Richard Purdie [EMAIL PROTECTED] wrote:
On Fri, 2007-05-25 at 17:15 +0530, Nitin Gupta wrote:
Richard, can you please provide perf. results for this patch also?
Also, can you please mail back latest version of your LZO
On Friday 25 May 2007 09:38:24 Richard Purdie wrote:
snip
I am however still strongly of the opinion that we should just use the
version in -mm (which is my latest version).
Right, if the difference is anything 10%, code cleanup does lose
its attractiveness.
Agreed, and I still have
On Friday 25 May 2007 12:55:21 Daniel Hazelton wrote:
snip
As to the performance - I can see absolutely no reason why the minimal
version shouldn't perform the same (or better). The kernel codes memset and
memcpy routines have been heavily tested *and* optimized over the years and
moving from
Hi Daniel,
On 5/26/07, Daniel Hazelton [EMAIL PROTECTED] wrote:
On Friday 25 May 2007 12:55:21 Daniel Hazelton wrote:
snip
As to the performance - I can see absolutely no reason why the minimal
version shouldn't perform the same (or better). The kernel codes memset and
memcpy routines have
42 matches
Mail list logo
