On 5/26/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
Hi Bret,
On 5/25/07, Bret Towe <[EMAIL PROTECTED]> wrote:
>
> [ 237.556167] LZO compress successful: orig_size=17448, comp_size=8183
> [ 253.320760] LZO decompress successful: decomp_size=17448
>
> 2221c586e3eb869af7f4333d4f56b441b9aa8414
Hi Bret,
On 5/25/07, Bret Towe <[EMAIL PROTECTED]> wrote:
[ 237.556167] LZO compress successful: orig_size=17448, comp_size=8183
[ 253.320760] LZO decompress successful: decomp_size=17448
2221c586e3eb869af7f4333d4f56b441b9aa8414 test-input
2e6c96b687274b629308b29835cebd3af989e0c7 output
Hi Pavel,
Just did some benchmarking; results below.
On 5/25/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
What is the performance difference between safe and unsafe version?
File size: 256K
- Following as tests for original test code - not any kernel port of this.
- Test with each block
On 25 May 2007, at 11:42, Pavel Machek wrote:
What is the performance difference between safe and unsafe version?
On 24 May 2007, at 23:26, Richard Purdie wrote:
For my minilzo kernel patch, the safe version showed a 7.2%
performance
hit.
The conclusion seemed to be that we should drop
Hi!
> Perhaps you have opinion of maintaining diffability with
> original LZO
> code which differs from mine. Since the code is now just
> ~500 lines it
> should be fair enough to have major overhauls for sake
> of clean
> KernelStyle(tm) code. It shouldn't be that hard to
> verify this small
Hi!
Perhaps you have opinion of maintaining diffability with
original LZO
code which differs from mine. Since the code is now just
~500 lines it
should be fair enough to have major overhauls for sake
of clean
KernelStyle(tm) code. It shouldn't be that hard to
verify this small
code
On 25 May 2007, at 11:42, Pavel Machek wrote:
What is the performance difference between safe and unsafe version?
On 24 May 2007, at 23:26, Richard Purdie wrote:
For my minilzo kernel patch, the safe version showed a 7.2%
performance
hit.
The conclusion seemed to be that we should drop
Hi Pavel,
Just did some benchmarking; results below.
On 5/25/07, Pavel Machek [EMAIL PROTECTED] wrote:
What is the performance difference between safe and unsafe version?
File size: 256K
- Following as tests for original test code - not any kernel port of this.
- Test with each block size
Hi Bret,
On 5/25/07, Bret Towe [EMAIL PROTECTED] wrote:
[ 237.556167] LZO compress successful: orig_size=17448, comp_size=8183
[ 253.320760] LZO decompress successful: decomp_size=17448
2221c586e3eb869af7f4333d4f56b441b9aa8414 test-input
2e6c96b687274b629308b29835cebd3af989e0c7 output
On 5/26/07, Nitin Gupta [EMAIL PROTECTED] wrote:
Hi Bret,
On 5/25/07, Bret Towe [EMAIL PROTECTED] wrote:
[ 237.556167] LZO compress successful: orig_size=17448, comp_size=8183
[ 253.320760] LZO decompress successful: decomp_size=17448
2221c586e3eb869af7f4333d4f56b441b9aa8414 test-input
On 5/25/07, Bret Towe <[EMAIL PROTECTED]> wrote:
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> On 5/25/07, Bret Towe <[EMAIL PROTECTED]> wrote:
> > On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> > > On 5/23/07, Bret Towe <[EMAIL PROTECTED]> wrote:
> > > > On 5/23/07, Nitin Gupta
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
On 5/25/07, Bret Towe <[EMAIL PROTECTED]> wrote:
> On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> > On 5/23/07, Bret Towe <[EMAIL PROTECTED]> wrote:
> > > On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> >
> > > > For now, tested on
On 5/24/07, Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/25/07, Bret Towe [EMAIL PROTECTED] wrote:
On 5/24/07, Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/23/07, Bret Towe [EMAIL PROTECTED] wrote:
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
For now, tested on x86 only.
If you
On 5/25/07, Bret Towe [EMAIL PROTECTED] wrote:
On 5/24/07, Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/25/07, Bret Towe [EMAIL PROTECTED] wrote:
On 5/24/07, Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/23/07, Bret Towe [EMAIL PROTECTED] wrote:
On 5/23/07, Nitin Gupta [EMAIL PROTECTED]
On 5/25/07, Bret Towe <[EMAIL PROTECTED]> wrote:
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> On 5/23/07, Bret Towe <[EMAIL PROTECTED]> wrote:
> > On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
>
> > > For now, tested on x86 only.
> >
> > If you have a program to test this I can run
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
On 5/23/07, Bret Towe <[EMAIL PROTECTED]> wrote:
> On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> > For now, tested on x86 only.
>
> If you have a program to test this I can run it on an amd64 and a g4 ppc
>
Attached is the kernel module
On Thu, 2007-05-24 at 15:54 -0700, Andrew Morton wrote:
> On Thu, 24 May 2007 23:41:22 +0100
> Richard Purdie <[EMAIL PROTECTED]> wrote:
>
> > I'll not send a "rename to unsafe" patch for the LZO core until Andrew
> > decides whether to drop the unsafe version entirely or not as per your
> >
On Thu, 24 May 2007 23:41:22 +0100
Richard Purdie <[EMAIL PROTECTED]> wrote:
> I'll not send a "rename to unsafe" patch for the LZO core until Andrew
> decides whether to drop the unsafe version entirely or not as per your
> patch. If he doesn't due to the potential use by the compressed cache
>
On Wed, 2007-05-23 at 15:33 +0100, Michael-Luke Jones wrote:
> On 23 May 2007, at 15:21, Nitin Gupta wrote:
>
> > If somebody is up to including compression he must be having head
> > to use the right
> > decompress version depending on this scenario :-)
>
> By that logic, experienced kernel
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
[...]
> > > diff --git a/lib/lzo1x/lzo1x_int.h b/lib/lzo1x/lzo1x_int.h
> > > [...]
> > > +/* Macros for 'safe' decompression */
> > > +#ifdef LZO1X_DECOMPRESS_SAFE
> > > +
> > > +#define lzo1x_decompress lzo1x_decompress_safe
> > > +#define
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
On 5/24/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> Hmm. The wrappers would clearly be inline, but if we want a common
> low-level decompress function, we'd also need to introduce the "if (safe &&)"
> kind of tests for those
On 5/24/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hmm. The wrappers would clearly be inline, but if we want a common
low-level decompress function, we'd also need to introduce the "if (safe &&)"
kind of tests for those differently-defined macros which could impact
performance (for the _unsafe
On 5/24/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
On Thu, 2007-05-24 at 01:04 +0530, Satyam Sharma wrote:
> On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
I remember this being mentioned. My answer was that this is the same
behaviour as the zlib library and you do not want to
On 5/23/07, Bret Towe <[EMAIL PROTECTED]> wrote:
On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> For now, tested on x86 only.
If you have a program to test this I can run it on an amd64 and a g4 ppc
Attached is the kernel module (compress-test) to test this LZO code.
Just compile
Hi Richard,
On 5/24/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
On Thu, 2007-05-24 at 01:04 +0530, Satyam Sharma wrote:
> On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> > [...]
> > +/* Macros for 'safe' decompression */
> > +#ifdef LZO1X_DECOMPRESS_SAFE
> > +
> > +#define
On 5/24/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
On 5/24/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> [...]
> Just defining and exporting LZO1X_WORKMEM_SIZE may not be enough
> to guarantee that users _will_ pass in workmem of size exactly that much.
>
> If this workmem is really merely a
On Thu, 2007-05-24 at 01:04 +0530, Satyam Sharma wrote:
> On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> > diff --git a/include/linux/lzo1x.h b/include/linux/lzo1x.h
> > [...]
> > +/* Size of temp buffer (workmem) required by lzo1x_compress */
> > +#define LZO1X_WORKMEM_SIZE ((size_t)
On Thu, 2007-05-24 at 01:04 +0530, Satyam Sharma wrote:
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
diff --git a/include/linux/lzo1x.h b/include/linux/lzo1x.h
[...]
+/* Size of temp buffer (workmem) required by lzo1x_compress */
+#define LZO1X_WORKMEM_SIZE ((size_t) (16384L *
On 5/24/07, Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/24/07, Satyam Sharma [EMAIL PROTECTED] wrote:
[...]
Just defining and exporting LZO1X_WORKMEM_SIZE may not be enough
to guarantee that users _will_ pass in workmem of size exactly that much.
If this workmem is really merely a temp buffer
Hi Richard,
On 5/24/07, Richard Purdie [EMAIL PROTECTED] wrote:
On Thu, 2007-05-24 at 01:04 +0530, Satyam Sharma wrote:
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
[...]
+/* Macros for 'safe' decompression */
+#ifdef LZO1X_DECOMPRESS_SAFE
+
+#define lzo1x_decompress
On 5/23/07, Bret Towe [EMAIL PROTECTED] wrote:
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
For now, tested on x86 only.
If you have a program to test this I can run it on an amd64 and a g4 ppc
Attached is the kernel module (compress-test) to test this LZO code.
Just compile this
On 5/24/07, Richard Purdie [EMAIL PROTECTED] wrote:
On Thu, 2007-05-24 at 01:04 +0530, Satyam Sharma wrote:
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
snip
I remember this being mentioned. My answer was that this is the same
behaviour as the zlib library and you do not want to
On 5/24/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hmm. The wrappers would clearly be inline, but if we want a common
low-level decompress function, we'd also need to introduce the if (safe )
kind of tests for those differently-defined macros which could impact
performance (for the _unsafe
On 5/24/07, Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/24/07, Satyam Sharma [EMAIL PROTECTED] wrote:
Hmm. The wrappers would clearly be inline, but if we want a common
low-level decompress function, we'd also need to introduce the if (safe )
kind of tests for those differently-defined macros
On 5/24/07, Nitin Gupta [EMAIL PROTECTED] wrote:
[...]
diff --git a/lib/lzo1x/lzo1x_int.h b/lib/lzo1x/lzo1x_int.h
[...]
+/* Macros for 'safe' decompression */
+#ifdef LZO1X_DECOMPRESS_SAFE
+
+#define lzo1x_decompress lzo1x_decompress_safe
+#define TEST_IP(ip ip_end)
On Wed, 2007-05-23 at 15:33 +0100, Michael-Luke Jones wrote:
On 23 May 2007, at 15:21, Nitin Gupta wrote:
If somebody is up to including compression he must be having head
to use the right
decompress version depending on this scenario :-)
By that logic, experienced kernel dev Richard
On Thu, 2007-05-24 at 15:54 -0700, Andrew Morton wrote:
On Thu, 24 May 2007 23:41:22 +0100
Richard Purdie [EMAIL PROTECTED] wrote:
I'll not send a rename to unsafe patch for the LZO core until Andrew
decides whether to drop the unsafe version entirely or not as per your
patch. If he
On Thu, 24 May 2007 23:41:22 +0100
Richard Purdie [EMAIL PROTECTED] wrote:
I'll not send a rename to unsafe patch for the LZO core until Andrew
decides whether to drop the unsafe version entirely or not as per your
patch. If he doesn't due to the potential use by the compressed cache
people,
On 5/24/07, Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/23/07, Bret Towe [EMAIL PROTECTED] wrote:
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
For now, tested on x86 only.
If you have a program to test this I can run it on an amd64 and a g4 ppc
Attached is the kernel module
On 5/25/07, Bret Towe [EMAIL PROTECTED] wrote:
On 5/24/07, Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/23/07, Bret Towe [EMAIL PROTECTED] wrote:
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
For now, tested on x86 only.
If you have a program to test this I can run it on an amd64 and
Hi Satyam,
Thanks for you comments.
On 5/24/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> diff --git a/include/linux/lzo1x.h b/include/linux/lzo1x.h
> [...]
> +/* Size of temp buffer (workmem) required by lzo1x_compress */
> +#define
On 5/23/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
On Wed, 2007-05-23 at 09:16 -0700, Andrew Morton wrote:
> On Wed, 23 May 2007 19:51:44 +0530 "Nitin Gupta" <[EMAIL PROTECTED]> wrote:
> > On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
> If so, it was quite inappropriate that a
Hi Nitin,
On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
[...]
diff --git a/Makefile b/Makefile
index 34210af..88053ba 100644
--- a/Makefile
+++ b/Makefile
@@ -826,11 +826,18 @@ include/config/kernel.release:
include/config/auto.conf FORCE
# Listed in dependency order
PHONY += prepare
On Wed, 2007-05-23 at 09:16 -0700, Andrew Morton wrote:
> On Wed, 23 May 2007 19:51:44 +0530 "Nitin Gupta" <[EMAIL PROTECTED]> wrote:
> > On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
> > If I rename 'nonsafe' version as such then it will seem like its a
> > 'broken' implementation
On Wed, 23 May 2007 19:51:44 +0530 "Nitin Gupta" <[EMAIL PROTECTED]> wrote:
> On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
> > On 23 May 2007, at 15:03, Nitin Gupta wrote:
> >
> > >> Perhaps a rename is in order:
> > >> lzo1x_decompress() => lzo1x_decompress_unsafe()
> > >>
On 5/23/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
Hi,
This contains LZO1X-1 compressor and LZO1X decompressor (safe and
standard version).
This includes changes suggested by various people - Thanks to all who
reviewed previous patches for this LZO port.
Changelog vs original LZO 2.02 code:
-
On 23 May 2007, at 15:21, Nitin Gupta wrote:
If somebody is up to including compression he must be having head
to use the right
decompress version depending on this scenario :-)
By that logic, experienced kernel dev Richard Purdie is not up to
using compression (?!)
To me, it looks like
On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
On 23 May 2007, at 15:03, Nitin Gupta wrote:
>> Perhaps a rename is in order:
>> lzo1x_decompress() => lzo1x_decompress_unsafe()
>> lzo1x_decompress_safe => lzo1x_decompress()
>
> Or perhaps make reiserfs use _safe() instead - I think
On 23 May 2007, at 15:03, Nitin Gupta wrote:
Perhaps a rename is in order:
lzo1x_decompress() => lzo1x_decompress_unsafe()
lzo1x_decompress_safe => lzo1x_decompress()
Or perhaps make reiserfs use _safe() instead - I think Richard has
already submitted patch for same.
If someone's already
On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
Fair enough. However, this rather important issue is pretty much
undocumented (source code comments don't count)
If header file for public interface ( documents about
'unsafe' vs. 'safe' then it should be enough.
and Reiser4 is
On 23 May 2007, at 12:39, Nitin Gupta wrote:
Hi Michael,
On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
I understand that the 'safe' decompression code is 'somewhat slower'
and that decompressor performance is a key feature of this algorithm.
However, I am concerned about the
Hi Michael,
On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
On 23 May 2007, at 09:27, Nitin Gupta wrote:
> This contains LZO1X-1 compressor and LZO1X decompressor (safe and
> standard version).
I understand that the 'safe' decompression code is 'somewhat slower'
and that
On 23 May 2007, at 09:27, Nitin Gupta wrote:
This contains LZO1X-1 compressor and LZO1X decompressor (safe and
standard version).
I understand that the 'safe' decompression code is 'somewhat slower'
and that decompressor performance is a key feature of this algorithm.
However, I am
Hi,
This contains LZO1X-1 compressor and LZO1X decompressor (safe and
standard version).
This includes changes suggested by various people - Thanks to all who
reviewed previous patches for this LZO port.
Changelog vs original LZO 2.02 code:
- Chopped down huge parts of original code that were
Hi,
This contains LZO1X-1 compressor and LZO1X decompressor (safe and
standard version).
This includes changes suggested by various people - Thanks to all who
reviewed previous patches for this LZO port.
Changelog vs original LZO 2.02 code:
- Chopped down huge parts of original code that were
On 23 May 2007, at 09:27, Nitin Gupta wrote:
This contains LZO1X-1 compressor and LZO1X decompressor (safe and
standard version).
I understand that the 'safe' decompression code is 'somewhat slower'
and that decompressor performance is a key feature of this algorithm.
However, I am
Hi Michael,
On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
On 23 May 2007, at 09:27, Nitin Gupta wrote:
This contains LZO1X-1 compressor and LZO1X decompressor (safe and
standard version).
I understand that the 'safe' decompression code is 'somewhat slower'
and that decompressor
On 23 May 2007, at 12:39, Nitin Gupta wrote:
Hi Michael,
On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
I understand that the 'safe' decompression code is 'somewhat slower'
and that decompressor performance is a key feature of this algorithm.
However, I am concerned about the safety
On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
Fair enough. However, this rather important issue is pretty much
undocumented (source code comments don't count)
If header file for public interface (linux/lzo1x.h documents about
'unsafe' vs. 'safe' then it should be enough.
and
On 23 May 2007, at 15:03, Nitin Gupta wrote:
Perhaps a rename is in order:
lzo1x_decompress() = lzo1x_decompress_unsafe()
lzo1x_decompress_safe = lzo1x_decompress()
Or perhaps make reiserfs use _safe() instead - I think Richard has
already submitted patch for same.
If someone's already made
On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
On 23 May 2007, at 15:03, Nitin Gupta wrote:
Perhaps a rename is in order:
lzo1x_decompress() = lzo1x_decompress_unsafe()
lzo1x_decompress_safe = lzo1x_decompress()
Or perhaps make reiserfs use _safe() instead - I think Richard has
On 23 May 2007, at 15:21, Nitin Gupta wrote:
If somebody is up to including compression he must be having head
to use the right
decompress version depending on this scenario :-)
By that logic, experienced kernel dev Richard Purdie is not up to
using compression (?!)
To me, it looks like
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
Hi,
This contains LZO1X-1 compressor and LZO1X decompressor (safe and
standard version).
This includes changes suggested by various people - Thanks to all who
reviewed previous patches for this LZO port.
Changelog vs original LZO 2.02 code:
-
On Wed, 23 May 2007 19:51:44 +0530 Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
On 23 May 2007, at 15:03, Nitin Gupta wrote:
Perhaps a rename is in order:
lzo1x_decompress() = lzo1x_decompress_unsafe()
lzo1x_decompress_safe =
On Wed, 2007-05-23 at 09:16 -0700, Andrew Morton wrote:
On Wed, 23 May 2007 19:51:44 +0530 Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
If I rename 'nonsafe' version as such then it will seem like its a
'broken' implementation which is not the
Hi Nitin,
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
[...]
diff --git a/Makefile b/Makefile
index 34210af..88053ba 100644
--- a/Makefile
+++ b/Makefile
@@ -826,11 +826,18 @@ include/config/kernel.release:
include/config/auto.conf FORCE
# Listed in dependency order
PHONY += prepare
On 5/23/07, Richard Purdie [EMAIL PROTECTED] wrote:
On Wed, 2007-05-23 at 09:16 -0700, Andrew Morton wrote:
On Wed, 23 May 2007 19:51:44 +0530 Nitin Gupta [EMAIL PROTECTED] wrote:
On 5/23/07, Michael-Luke Jones [EMAIL PROTECTED] wrote:
If so, it was quite inappropriate that a filesystem be
Hi Satyam,
Thanks for you comments.
On 5/24/07, Satyam Sharma [EMAIL PROTECTED] wrote:
On 5/23/07, Nitin Gupta [EMAIL PROTECTED] wrote:
diff --git a/include/linux/lzo1x.h b/include/linux/lzo1x.h
[...]
+/* Size of temp buffer (workmem) required by lzo1x_compress */
+#define
68 matches
Mail list logo
