From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Vaneet Narang <v.narang@samsung.com>
Cc: Maninder Singh <maninder1.s@samsung.com>,
"sergey.senozhatsky.work@gmail.com"
<sergey.senozhatsky.work@gmail.com>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"minchan@kernel.org" <minchan@kernel.org>,
"ngupta@vflare.org" <ngupta@vflare.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"anton@enomsg.org" <anton@enomsg.org>,
"ccross@android.com" <ccross@android.com>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"colin.king@canonical.com" <colin.king@canonical.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
PANKAJ MISHRA <pankaj.m@samsung.com>,
AMIT SAHRA
Subject: Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.
Date: Wed, 4 Apr 2018 10:40:23 +0900 [thread overview]
Message-ID: <20180404014023.GA5087@jagdpanzerIV> (raw)
In-Reply-To: <576192949.596772.1522763027665.JavaMail.jboss@ep1ml501>
On (04/03/18 19:13), Vaneet Narang wrote:
> Hi Sergey,
>
> >You shrink a 2 bytes offset down to a 1 byte offset, thus you enforce that
> 2 Byte offset is not shrinked to 1 byte, Its only 1 bit is reserved out of
> 16 bits of offset. So only 15 Bits can be used to store offset value.
Yes, you are right. My bad, was thinking about something else.
> >'page should be less than 32KB', which I'm sure will be confusing.
> lz4_dyn will work on bigger data length(> 32k) but in that case compression
> ratio may not be better than LZ4. This is same as LZ4 compressing data more
> than 64K (16Bits). LZ4 can't store offset more than 64K similarly
> LZ4 dyn can't store offset more than 32K.
Then drop that `if PAGE_SIZE' thing. I'd rather do that stuff internally
in lz4... if it needed at all.
> >And you
> >rely on lz4_dyn users to do the right thing - namely, to use that 'nice'
> >`#if (PAGE_SIZE < (32 * KB))'.
> They don't need to add this code
Then drop it.
> >Apart from that, lz4_dyn supports only data
> >in up to page_size chunks. Suppose my system has page_size of less than 32K,
> >so I legitimately can enable lz4_dyn, but suppose that I will use it
> >somewhere where I don't work with page_size-d chunks. Will I able to just
> >do tfm->compress(src, sz) on random buffers? The whole thing looks to be
> >quite fragile.
> No thats not true, lz4_dyn can work for random buffers and it need not be
> of page size chunks. There is no difference in Lz4 and Lz4 dyn working.
You are right.
-ss
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Vaneet Narang <v.narang@samsung.com>
Cc: Maninder Singh <maninder1.s@samsung.com>,
"sergey.senozhatsky.work@gmail.com"
<sergey.senozhatsky.work@gmail.com>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"minchan@kernel.org" <minchan@kernel.org>,
"ngupta@vflare.org" <ngupta@vflare.org>,
"keescook@chromium.org" <keescook@chromium.org>,
"anton@enomsg.org" <anton@enomsg.org>,
"ccross@android.com" <ccross@android.com>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"colin.king@canonical.com" <colin.king@canonical.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
PANKAJ MISHRA <pankaj.m@samsung.com>,
AMIT SAHRAWAT <a.sahrawat@samsung.com>
Subject: Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.
Date: Wed, 4 Apr 2018 10:40:23 +0900 [thread overview]
Message-ID: <20180404014023.GA5087@jagdpanzerIV> (raw)
In-Reply-To: <576192949.596772.1522763027665.JavaMail.jboss@ep1ml501>
On (04/03/18 19:13), Vaneet Narang wrote:
> Hi Sergey,
>
> >You shrink a 2 bytes offset down to a 1 byte offset, thus you enforce that
> 2 Byte offset is not shrinked to 1 byte, Its only 1 bit is reserved out of
> 16 bits of offset. So only 15 Bits can be used to store offset value.
Yes, you are right. My bad, was thinking about something else.
> >'page should be less than 32KB', which I'm sure will be confusing.
> lz4_dyn will work on bigger data length(> 32k) but in that case compression
> ratio may not be better than LZ4. This is same as LZ4 compressing data more
> than 64K (16Bits). LZ4 can't store offset more than 64K similarly
> LZ4 dyn can't store offset more than 32K.
Then drop that `if PAGE_SIZE' thing. I'd rather do that stuff internally
in lz4... if it needed at all.
> >And you
> >rely on lz4_dyn users to do the right thing - namely, to use that 'nice'
> >`#if (PAGE_SIZE < (32 * KB))'.
> They don't need to add this code
Then drop it.
> >Apart from that, lz4_dyn supports only data
> >in up to page_size chunks. Suppose my system has page_size of less than 32K,
> >so I legitimately can enable lz4_dyn, but suppose that I will use it
> >somewhere where I don't work with page_size-d chunks. Will I able to just
> >do tfm->compress(src, sz) on random buffers? The whole thing looks to be
> >quite fragile.
> No thats not true, lz4_dyn can work for random buffers and it need not be
> of page size chunks. There is no difference in Lz4 and Lz4 dyn working.
You are right.
-ss
next prev parent reply other threads:[~2018-04-04 1:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180321044137epcas5p221e7ee4a0b7464eaa00dad8320f0251d@epcas5p2.samsung.com>
2018-03-21 4:40 ` [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length Maninder Singh
2018-03-21 4:40 ` [PATCH 1/1] lz4: " Maninder Singh
2018-03-21 7:49 ` Sergey Senozhatsky
2018-04-02 5:51 ` Maninder Singh
2018-04-03 12:26 ` Sergey Senozhatsky
2018-04-03 12:26 ` Sergey Senozhatsky
2018-04-03 13:43 ` Vaneet Narang
2018-04-04 1:40 ` Sergey Senozhatsky [this message]
2018-04-04 1:40 ` Sergey Senozhatsky
2018-03-21 19:59 ` Nick Terrell
2018-03-22 4:28 ` Maninder Singh
2018-03-23 13:21 ` Vaneet Narang
2018-03-22 23:09 ` kbuild test robot
2018-03-22 23:32 ` kbuild test robot
2018-03-21 6:41 ` [PATCH 0/1] cover-letter/lz4: " Sergey Senozhatsky
2018-04-02 6:03 ` Maninder Singh
2018-04-02 6:03 ` Maninder Singh
2018-03-21 8:26 ` Sergey Senozhatsky
2018-03-21 19:56 ` Nick Terrell
2018-03-21 19:56 ` Nick Terrell
2018-03-22 2:43 ` Sergey Senozhatsky
2018-03-22 2:43 ` Sergey Senozhatsky
2018-03-23 13:43 ` Vaneet Narang
[not found] ` <CGME20180321044137epcas5p221e7ee4a0b7464eaa00dad8320f0251d@epcms5p6>
[not found] ` <20180329102046epcms5p8ecc9532b03bab4f47cbdbb2507171b86@epcms5p8>
2018-03-29 10:26 ` Maninder Singh
2018-03-29 10:26 ` Maninder Singh
2018-03-30 5:41 ` Sergey Senozhatsky
2018-03-30 5:41 ` Sergey Senozhatsky
2018-04-16 10:21 ` Maninder Singh
2018-04-16 19:34 ` Yann Collet
2018-04-16 20:01 ` Eric Biggers
2018-04-16 20:01 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180404014023.GA5087@jagdpanzerIV \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=colin.king@canonical.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=keescook@chromium.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maninder1.s@samsung.com \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=pankaj.m@samsung.com \
--cc=tony.luck@intel.com \
--cc=v.narang@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.