From: Nick Terrell <terrelln@fb.com>
To: Minchan Kim <minchan@kernel.org>
CC: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        "sergey.senozhatsky.work@gmail.com" 
        <sergey.senozhatsky.work@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Yann Collet <cyan@fb.com>
Subject: Re: [PATCH] zram: add zstd to the supported algorithms list
Thread-Topic: [PATCH] zram: add zstd to the supported algorithms list
Thread-Index: AQHTHSCvXWqWlMVfbUKYI//VGek9A6KUPdeA//+XcYCAALPlgIAAeKYA
Date: Fri, 25 Aug 2017 19:31:14 +0000
Message-ID: <315465C2-671F-4165-970E-B74ACFB9398D@fb.com>
References: <20170824014936.4738-1-sergey.senozhatsky@gmail.com>
 <AA6434F2-6932-436E-B063-B6C0417A553C@contoso.com>
 <20170825004947.GE29701@js1304-P5Q-DELUXE>
 <27EDD68A-61DC-42F1-8422-16B9AB9F0EB3@fb.com>
 <20170825051925.GB26819@blaptop>
In-Reply-To: <20170825051925.GB26819@blaptop>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <AE0C9C2286CAE8489AD6E8734EADCC10@namprd15.prod.outlook.com>
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2017 19:31:15.0511
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1114
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-08-25_05:,,
 signatures=0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nfs id v7PJVUUC018443
Content-Length: 2866
Lines: 64

On 8/24/17, 10:19 PM, "Minchan Kim" <minchan@kernel.org> wrote:
> On Fri, Aug 25, 2017 at 01:35:35AM +0000, Nick Terrell wrote:
[..]
> > I think using dictionaries in zram could be very interesting. We could for
> > example, take a random sample of the RAM and use that as the dictionary
> > for compression. E.g. take 32 512B samples from RAM and build a 16 KB
> > dictionary (sizes may vary).
> 
> For static option, could we create the dictionary with data in zram
> and dump the dictionary into file. And then, rebuiling zram or kernel
> includes the dictionary into images.
> 
> For it, we would need some knob like
> 
>         cat /sys/block/zram/zstd_dict > dict.data
> 
>         CONFIG_ZSTD_DICT_DIR=
>         CONFIG_ZSTD_DICT_FILE= 

My guess is that a static dictionary won't cut it, since different
workloads will have drastically different RAM contents, so we won't be able
to construct a single dictionary that works for them all. I'd love to be
proven wrong though.

> For dynamic option, could we make the dictionary with data
> in zram dynamically? So, upcoming pages will use the newly
> created dictionary but old compressed pages will use own dictionary.

Yeah thats totally possible on the compression side, we would just need to
save which pages were compressed with which dictionary somewhere.

> I'm not sure it's possible, anyway, if predefined dict can help
> comp ratio a lot in 4K data, I really love the feature and will support
> to have it. ;)
> 
> > 
> > I'm not sure how you would pass a dictionary into the crypto compression
> > API, but I'm sure we can make something work if dictionary compression
> > proves to be beneficial enough.
> 
> Yes, it would be better to integrate the feature crypto but Please, don't tie to
> crypto API. If it's hard to support with current cypto API in short time,
> I really want to support it with zcomp_zstd.c.
> 
> Please look at old zcomp model.
> http://elixir.free-electrons.com/linux/v4.7/source/drivers/block/zram/zcomp_lz4.c

Thanks for the link, we could definitely make zcomp work with dictionaries.

> > What data have you, or anyone, used for benchmarking compression ratio and 
> > speed for RAM? Since it is such a specialized application, the standard
> > compression benchmarks aren't very applicable.
> 
> I have used my image dumped from desktop swap device.
> Of course, it doesn't cover all of cases in the world but it would be better
> to use IO benchmark buffer, IMHO. :)

Since adding dictionary support won't be quite as easy as adding zstd
support, I think the first step is building a set of benchmarks that
represent some common real world scenarios. We can easily test different
dictionary construction algorithms in userspace, and determine if the work
will pay off for some workloads. I'll collect some RAM samples from my
device and run some preliminary tests.