From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by kanga.kvack.org (Postfix) with ESMTP id 431396B0376 for ; Mon, 29 Oct 2018 08:27:51 -0400 (EDT) Received: by mail-lj1-f197.google.com with SMTP id s14-v6so3220593lji.2 for ; Mon, 29 Oct 2018 05:27:51 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id q7-v6sor11560697ljj.17.2018.10.29.05.27.48 for (Google Transport Security); Mon, 29 Oct 2018 05:27:49 -0700 (PDT) MIME-Version: 1.0 References: <20181025112821.0924423fb9ecc7918896ec2b@gmail.com> <20181025124249.0ba63f1041ed8836ff6e6190@linux-foundation.org> In-Reply-To: <20181025124249.0ba63f1041ed8836ff6e6190@linux-foundation.org> From: Vitaly Wool Date: Mon, 29 Oct 2018 13:27:36 +0100 Message-ID: Subject: Re: [PATCH] z3fold: encode object length in the handle Content-Type: multipart/alternative; boundary="00000000000064cb7905795d32a2" Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Linux-MM , LKML , Oleksiy.Avramchenko@sony.com, Guenter Roeck --00000000000064cb7905795d32a2 Content-Type: text/plain; charset="UTF-8" Hi Andrew, Den tors 25 okt. 2018 kl 21:42 skrev Andrew Morton < akpm@linux-foundation.org>: > On Thu, 25 Oct 2018 11:28:21 +0200 Vitaly Wool > wrote: > > > Reclaim and free can race on an object (which is basically ok) but > > in order for reclaim to be able to map "freed" object we need to > > encode object length in the handle. handle_to_chunks() is thus > > introduced to extract object length from a handle and use it during > > mapping of the last object we couldn't correctly map before. > > What are the runtime effects of this change? > I haven't observed any adverse impact with this change used in zswap (and in fact, this is a bugfix for zswap operation). There is a slight under 1% impact when z3fold is used with ZRAM but since the support for ZRAM over zpool is still out of tree, I take it doesn't matter at this point, right? Best regards, Vitaly --00000000000064cb7905795d32a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Andrew,

Den tors 25 okt. 2018 kl 21:42 skrev Andrew Morton <akpm@linux-foundation.org>:
On Thu, 25 Oct 2018 11:28:21 +0200 Vitaly= Wool <vitalyw= ool@gmail.com> wrote:

> Reclaim and free can race on an object (which is basically ok) but
> in order for reclaim to be able to=C2=A0 map "freed" object = we need to
> encode object length in the handle. handle_to_chunks() is thus
> introduced to extract object length from a handle and use it during > mapping of the last object we couldn't correctly map before.

What are the runtime effects of this change?

I haven't observed any adverse impact with this change used in zs= wap (and in fact, this is a bugfix for zswap operation). There is a slight = under 1% impact when z3fold is used with ZRAM but since the support for ZRA= M over zpool is still out of tree, I take it doesn't matter at this poi= nt, right?

Best regards,
=C2=A0=C2=A0 Vi= taly
--00000000000064cb7905795d32a2--