On Mon, Apr 16, 2018 at 07:34:29PM +, Yann Collet wrote:
> Hi Singh
>
> I don't have any strong opinion on this topic.
>
> You made your case clear:
> your variant trades a little bit of speed for a little bit more compression
> ratio.
> In the context of zram, it makes sense, and I would e
Hi Singh
I don't have any strong opinion on this topic.
You made your case clear:
your variant trades a little bit of speed for a little bit more compression
ratio.
In the context of zram, it makes sense, and I would expect it to work, as
advertised in your benchmark results.
(disclaimer: I ha
Hello Nick/ Yann,
Any inputs regarding LZ4 dyn results & lz4 dyn approach.
>Hello Nick/Sergey,
>
>Any suggestion or comments, so that we can change code and resend the patch?
>
>> Hi Nick / Sergey,
>>
>>
>> We have compared LZ4 Dyn with Original LZ4 using some samples of realtime
>> applic
Hello,
>> (Added cover letter to avoid much text in patch description)
>>
>> LZ4 specification defines 2 byte offset length for 64 KB data.
>> But in case of ZRAM we compress data per page and in most of
>> architecture PAGE_SIZE is 4KB. So we can decide offset length based
>> on actual offset
On (03/29/18 15:56), Maninder Singh wrote:
> Hello Nick/Sergey,
>
> Any suggestion or comments, so that we can change code and resend the patch?
Well... there were no replies to
https://marc.info/?l=linux-kernel&m=152161450026771&w=2
and
https://marc.info/?l=linux-kernel&m=152161860627974&w=2
Hello Nick/Sergey,
Any suggestion or comments, so that we can change code and resend the patch?
> Hi Nick / Sergey,
>
>
> We have compared LZ4 Dyn with Original LZ4 using some samples of realtime
>application data(4Kb)
> compressed/decompressed by ZRAM. For comparison we have used lzbench
Hi Nick / Sergey,
We have compared LZ4 Dyn with Original LZ4 using some samples of realtime
application data(4Kb)
compressed/decompressed by ZRAM. For comparison we have used lzbench
(https://github.com/inikep/lzbench)
we have implemented dedicated LZ4 Dyn API & kept last literal length as 6 to
On (03/21/18 19:56), Nick Terrell wrote:
[..]
> This seems like a reasonable extension to the algorithm, and it looks like
> LZ4_DYN is about a 5% improvement to compression ratio on your benchmark.
> The biggest question I have is if it is worthwhile to maintain a separate
> incompatible variant o
On (03/21/18 10:10), Maninder Singh wrote:
> LZ4 specification defines 2 byte offset length for 64 KB data.
> But in case of ZRAM we compress data per page and in most of
> architecture PAGE_SIZE is 4KB. So we can decide offset length based
> on actual offset value. For this we can reserve 1 bit to
CC-ing Nick
Nick, can you take a look?
Message-IDs:
lkml.kernel.org/r/1521607242-3968-1-git-send-email-maninder...@samsung.com
lkml.kernel.org/r/1521607242-3968-2-git-send-email-maninder...@samsung.com
-ss
On (03/21/18 10:10), Maninder Singh wrote:
> (Added cover letter to avoid much text in patch description)
>
> LZ4 specification defines 2 byte offset length for 64 KB data.
> But in case of ZRAM we compress data per page and in most of
> architecture PAGE_SIZE is 4KB. So we can decide offset lengt
(Added cover letter to avoid much text in patch description)
LZ4 specification defines 2 byte offset length for 64 KB data.
But in case of ZRAM we compress data per page and in most of
architecture PAGE_SIZE is 4KB. So we can decide offset length based
on actual offset value. For this we can reser
12 matches
Mail list logo
