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 1953AC433FE for ; Wed, 23 Nov 2022 08:53:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86D3D6B0071; Wed, 23 Nov 2022 03:53:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 81CF56B0073; Wed, 23 Nov 2022 03:53:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70B006B0074; Wed, 23 Nov 2022 03:53:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 622626B0071 for ; Wed, 23 Nov 2022 03:53:17 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E66751C6A13 for ; Wed, 23 Nov 2022 08:53:16 +0000 (UTC) X-FDA: 80164092792.27.E836075 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by imf13.hostedemail.com (Postfix) with ESMTP id DC21820009 for ; Wed, 23 Nov 2022 08:53:15 +0000 (UTC) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id E45685FD05; Wed, 23 Nov 2022 11:53:13 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1669193593; bh=EFUj1UfeBU4lrWGe8L6tswKd0unOyhOedJJPTmNlouY=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=SbRe53/WmTFlRN+ALDK4FXfRTFqIShTM4LjPVmpjwhZlUC32G4JpBTWqXpJNY7yT4 yDaYK53NUbhvO51XbJPS/eo6jq6VKrCd4wjzd4ufhSTOZnnyI9LJpm8vPutzTna1rc 2insrmgxK4jzUfKBEdF/7B61UyQANIxmIHBptrc3KZKQijZ6Isfssq/t5O0lhBY7Ep 4Gw0q0g2ce0POzINaQRPaEUcyAcrGQpc4u1NHLsZWU6WXphQVq1sjX2PwZnSR9Jk8h +077W9Ahr+d29+md32q1FUYAFNCDzzV6ABePMITSlrNv0dUuWa1XxvsMvL3uhHIllr Tbh7abN8pgRAg== 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 11:53:12 +0300 (MSK) Date: Wed, 23 Nov 2022 11:53:06 +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: <20221123085306.52ozfjimaeikcbof@CAB-WSD-L081021> References: <20221121190020.66548-1-avromanov@sberdevices.ru> <20221122121413.ssieckg523urj37h@cab-wsm-0029881.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20220415 X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH02.sberdevices.ru (172.16.1.5) 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/11/23 05:15:00 #20600357 X-KSMG-AntiVirus-Status: Clean, skipped ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669193596; a=rsa-sha256; cv=none; b=YX+cK/TOt8fhCyluGh3olkeDZoMrcyPJsHrGbhzaVsmm1tcW2KGC205z58fsexrz608kBc TNQJZFC/ZwIz7TbG0UKd9ndWMwLWiuoqHvNNzNMN9pPc2gdke6ltT/Rd910NBhgmxlqoOF KNTsFcIDBUb0k/LLnzA/wrSSi3wOEm4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=sberdevices.ru header.s=mail header.b="SbRe53/W"; dmarc=pass (policy=quarantine) header.from=sberdevices.ru; spf=pass (imf13.hostedemail.com: domain of DDRokosov@sberdevices.ru designates 45.89.227.171 as permitted sender) smtp.mailfrom=DDRokosov@sberdevices.ru ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669193596; 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=EFUj1UfeBU4lrWGe8L6tswKd0unOyhOedJJPTmNlouY=; b=yAwN5mvag8psrc7MpvBl5/R8jUqSNCWlIA4/TEnUMZg3t7Ip3esAVGGh2U//Rx8RbZO+dZ lQgs9YzlHrtjkI1BiPjkJEA4kTiorKItmiJhLNI3bwBG291BeuODPe4jy5GYe2AF7dkK6Q UcXwDLmeIH8kXQS15hz/5wi0rlFjr+U= X-Stat-Signature: drrdfkg59r537yehti19h4ewmfp6k5fj X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DC21820009 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=sberdevices.ru header.s=mail header.b="SbRe53/W"; dmarc=pass (policy=quarantine) header.from=sberdevices.ru; spf=pass (imf13.hostedemail.com: domain of DDRokosov@sberdevices.ru designates 45.89.227.171 as permitted sender) smtp.mailfrom=DDRokosov@sberdevices.ru X-Rspam-User: X-HE-Tag: 1669193595-102802 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, 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