From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C81DEC4332F for ; Wed, 23 Nov 2022 09:07:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E02C6B0071; Wed, 23 Nov 2022 04:07:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 490066B0073; Wed, 23 Nov 2022 04:07:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3590D6B0074; Wed, 23 Nov 2022 04:07:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 276F26B0071 for ; Wed, 23 Nov 2022 04:07:44 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DB443C119C for ; Wed, 23 Nov 2022 09:07:43 +0000 (UTC) X-FDA: 80164129206.02.8CD1DC3 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by imf04.hostedemail.com (Postfix) with ESMTP id 1010840008 for ; Wed, 23 Nov 2022 09:07:42 +0000 (UTC) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id 58CFE5FD05; Wed, 23 Nov 2022 12:07:41 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1669194461; bh=xF2LqQnAmt9x2NwV89/RQYiuJ8szJL/yCkefPCbEAkg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=dTX0CzUQjFUGbZD15aRoquNKkkaEASXHDIVpsmg6jI7nmBLLH0kg+LovniGLl+af0 xNFv1aHqOqU3TEoibDolerwkyGmyJ7HD7gk8HkkPZo4XZrWlIjaRW8IQEftWNax9hM lzJ3Oeu8WgUigSi8xmZxnslXqn5eDWeftQpJxnb6GRrq+WUHAiSL4jwb413iCEwGiq cyrhG+24QjmX02wVEin+VepOi0DxWI04D9AXc/btHWvOGmxT3SeVgJ+arEEKsH8ete UHJLn73CAn2BVCdJi64BRK1MW5/jprQTiYnz0zLnfqYDZur/hTP9kTpO4Zv+c8O8kp DqOA4Fsdjp+rA== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Wed, 23 Nov 2022 12:07:41 +0300 (MSK) From: Aleksey Romanov To: Sergey Senozhatsky CC: Johannes Weiner , "minchan@kernel.org" , "ngupta@vflare.org" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , kernel , "Dmitry Rokosov" Subject: Re: [RFC PATCH v1 0/4] Introduce merge identical pages mechanism Thread-Topic: [RFC PATCH v1 0/4] Introduce merge identical pages mechanism Thread-Index: AQHY/duSaivivX4eVEi4n5R4teXteK5JpjKAgABo/ACAAAH8AIAAmLKAgAEMI4CAAFIJAA== Date: Wed, 23 Nov 2022 09:07:40 +0000 Message-ID: <20221123090732.7aktww2jk6axdrld@cab-wsm-0029881.lan> References: <20221121190020.66548-1-avromanov@sberdevices.ru> <20221122121413.ssieckg523urj37h@cab-wsm-0029881.lan> In-Reply-To: Accept-Language: ru-RU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.1.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <2068E6DE403ECC48BB19CC683B9416B6@sberdevices.ru> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2022/11/23 05:15:00 #20600357 X-KSMG-AntiVirus-Status: Clean, skipped ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669194463; a=rsa-sha256; cv=none; b=rKWZG29ke09irphFcKOdPlSGhC56LQANRUMP7JZUSasN7Uq7oNMIh8y8Mi7nWSuRKzukMl NMMV7K0uOnuQXCn6HAV3wfzrffAMnHnf3TtDgqiXYU+nhDks5xkHclzAJm36rm8w4QUnvE g4BGO7QJUuJuL7ZZ+gj8wibXynW3cyA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=sberdevices.ru header.s=mail header.b=dTX0CzUQ; spf=pass (imf04.hostedemail.com: domain of AVRomanov@sberdevices.ru designates 45.89.227.171 as permitted sender) smtp.mailfrom=AVRomanov@sberdevices.ru; dmarc=pass (policy=quarantine) header.from=sberdevices.ru ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669194463; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=xF2LqQnAmt9x2NwV89/RQYiuJ8szJL/yCkefPCbEAkg=; b=WougQW4+614EmF+J6skWrzUmWv2FeWA3hotV9zmm6iXDweU8P4WKQSyb66eG4BGSFFJ8if eDytsW126UmNmylBae2E5VZxFpQ0i1/iY31KJWQZn4reyUbDtJsf+Xcvmh6UfLT9xJcVOA sx2NBfdvcK+92jWuBZz/0S85xBA36Fk= X-Stat-Signature: a1yn6sjywqbsjtukeeshr5ekika3g8k3 X-Rspamd-Queue-Id: 1010840008 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=sberdevices.ru header.s=mail header.b=dTX0CzUQ; spf=pass (imf04.hostedemail.com: domain of AVRomanov@sberdevices.ru designates 45.89.227.171 as permitted sender) smtp.mailfrom=AVRomanov@sberdevices.ru; dmarc=pass (policy=quarantine) header.from=sberdevices.ru X-Rspamd-Server: rspam02 X-HE-Tag: 1669194462-955385 X-Bogosity: Ham, tests=bogofilter, spamicity=0.002646, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Nov 23, 2022 at 01:13:55PM +0900, Sergey Senozhatsky wrote: > On (22/11/22 12:14), Aleksey Romanov wrote: > > > IIRC that was patent in question: > > >=20 > > > https://patentimages.storage.googleapis.com/e2/66/9e/0ddbfae5c182ac/U= S9977598.pdf > >=20 > > I think the patent is talking about "mapping the virtual address" (like > > in KSM). But zram works with the "handle" abstraction, which is a boxed > > pointer to the required object. I think my implementation and the paten= t > > is slightly different.=20 > >=20 > > Also, the patent speaks of "compressing" pages. In this case, we can ad= d > > zs_merge() function (like zs_compact()), that is, remove the merge logi= c > > at the allocator level. zsmalloc doesn't say anything about what object= s > > it can work with. Implementation at the zsmalloc level is possible, > > though more complicated that at the zram level.=20 > >=20 > > I believe that we can implement at least one of the options I proposed. > >=20 > > What do you think? >=20 > Oh, yeah, I'm not saying that we cannot have something like that > in zram/zsmalloc, just wanted to give some historical retrospective > on this and point at some implementation details that should be > considered. Okay, in this case, can you review my patches please? --=20 Thank you, Alexey=