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 3B912C43217 for ; Thu, 1 Dec 2022 10:14:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4ED866B0072; Thu, 1 Dec 2022 05:14:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 49D236B0073; Thu, 1 Dec 2022 05:14:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 364E66B0074; Thu, 1 Dec 2022 05:14:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 240616B0072 for ; Thu, 1 Dec 2022 05:14:28 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E195AC0D3B for ; Thu, 1 Dec 2022 10:14:27 +0000 (UTC) X-FDA: 80193327774.22.96EA282 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by imf28.hostedemail.com (Postfix) with ESMTP id AC603C0012 for ; Thu, 1 Dec 2022 10:14:26 +0000 (UTC) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id A10285FD07; Thu, 1 Dec 2022 13:14:24 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1669889664; bh=wl7vBDIsPjcpk2GTYMr4D53WkGXWEKQGydGiDJhgcJ4=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=ZlAKr8tr87vLzNtu9IoGhy7OJeYNjwXj674qCLXgQajfS+7NrmpXt6IoDaKl0EhPc n/XNytEia+Mx+doFKxevtGGfFgGWv7nZpK3V7iOxi5cd53PXoee7CiBDTE9aSaSyAZ 9XaQVdTr/2LGOovlyPWNeWlF55lHlVqFb6CrgHl1oDVyXEuvi/RZxefiihtLR+fAO2 iTZdDXwC4umABxJMGf5L7EE5yfX9coIyrJdz0Ha+lBNSJ5PkH4Ne/VqssI9+xuagx1 bv+vsg/G95WS3gTZPzf1ScbYWUwJ2ZQN+ve1kG/uPyTRHmbywWTrtdWiMN0qyIo09Y iOs1kNteadEaQ== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Thu, 1 Dec 2022 13:14:23 +0300 (MSK) Date: Thu, 1 Dec 2022 13:14:17 +0300 From: Dmitry Rokosov To: Sergey Senozhatsky CC: Aleksey Romanov , Johannes Weiner , "minchan@kernel.org" , "ngupta@vflare.org" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , kernel Subject: Re: [RFC PATCH v1 0/4] Introduce merge identical pages mechanism Message-ID: <20221201101417.f6qm4v3m7ibh3l72@CAB-WSD-L081021> References: <20221121190020.66548-1-avromanov@sberdevices.ru> <20221122121413.ssieckg523urj37h@cab-wsm-0029881.lan> <20221123085306.52ozfjimaeikcbof@CAB-WSD-L081021> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20221123085306.52ozfjimaeikcbof@CAB-WSD-L081021> User-Agent: NeoMutt/20220415 X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH01.sberdevices.ru (172.16.1.4) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) 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/12/01 00:48:00 #20630840 X-KSMG-AntiVirus-Status: Clean, skipped ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=sberdevices.ru header.s=mail header.b=ZlAKr8tr; spf=pass (imf28.hostedemail.com: domain of DDRokosov@sberdevices.ru designates 45.89.227.171 as permitted sender) smtp.mailfrom=DDRokosov@sberdevices.ru; dmarc=pass (policy=quarantine) header.from=sberdevices.ru ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669889667; a=rsa-sha256; cv=none; b=z+Kxwqd1gGwruPhxRKGehX03YFFFDqY4Frl8XxEQkszGY2RYGKcmUIr7MG/FyiDqjcZV8X gFJdOoK5I905nKWKzh/ibrMFMA+Y1nPmf1CpMr3CCzUZx32Ijt9I+coeRvHm683kK0flGn l8h/YUFE4IZoJ8azi+YLZ4N6zopctZE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669889667; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wl7vBDIsPjcpk2GTYMr4D53WkGXWEKQGydGiDJhgcJ4=; b=j7KVexUpGxcHDCrv32pkDyftcNMWi+F0FrGaBiBRdE9m9hSZHB78qhFkjMnQan0TvUiZfT Lhwk1JRjvke74Op8SbIl0qJJ9GbUaEu6cQb9OlnHPCZbqVHgTd0wWNzF/9dmlR1MGmfeIJ bCDEKhzEE4ivSrhwKOkca3Np7UBOHIY= X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AC603C0012 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=sberdevices.ru header.s=mail header.b=ZlAKr8tr; spf=pass (imf28.hostedemail.com: domain of DDRokosov@sberdevices.ru designates 45.89.227.171 as permitted sender) smtp.mailfrom=DDRokosov@sberdevices.ru; dmarc=pass (policy=quarantine) header.from=sberdevices.ru X-Stat-Signature: 8oefa31nm1s48in5ct1zpdyhzxdrgjni X-HE-Tag: 1669889666-448135 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello Sergey, Hope you are doing well. Really sorry for the ping. Did you get a chance to see the patch series, my questions, and thoughts? On Wed, Nov 23, 2022 at 11:53:06AM +0300, Dmitry Rokosov wrote: > Hello Sergey, > > Thank you for your quick and detailed support! Here is my two cents > below. > > 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: > > > > > > > > https://patentimages.storage.googleapis.com/e2/66/9e/0ddbfae5c182ac/US9977598.pdf > > > > > > 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 patent > > > is slightly different. > > > > > > Also, the patent speaks of "compressing" pages. In this case, we can add > > > zs_merge() function (like zs_compact()), that is, remove the merge logic > > > at the allocator level. zsmalloc doesn't say anything about what objects > > > it can work with. Implementation at the zsmalloc level is possible, > > > though more complicated that at the zram level. > > > > > > I believe that we can implement at least one of the options I proposed. > > > > > > What do you think? > > > > 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. > > It's a very curious situation, I would say. I'm not so familiar with US > patent law, but I suppose it should be based on some keywords and > algorithms. > > If we speak in terms of algorithm Alexey patch is different a little bit > from suggested in the patent paper. If we care about keywords, I think by > moving Alexey same page merging algorithm to zsmalloc we lose > "compressing" keyword, because zsmalloc operates with "objects" only, > doesn't matter if they are compressed or not. > > Anyway, could you please suggest who can help to understand if it's safe > to use such same page merging algorithm in the upstream or not? > Maybe we can ask Linux Foundation lawyers to help us, just a guess. > I'm sure we shouldn't decline helpful features and optimization without > complete certainty about all restrictions. -- Thank you, Dmitry