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 54F02C4332F for ; Wed, 23 Nov 2022 04:14:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C70B96B0071; Tue, 22 Nov 2022 23:14:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C20D86B0073; Tue, 22 Nov 2022 23:14:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AE87E8E0001; Tue, 22 Nov 2022 23:14:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A083D6B0071 for ; Tue, 22 Nov 2022 23:14:02 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 74B13AB0AE for ; Wed, 23 Nov 2022 04:14:02 +0000 (UTC) X-FDA: 80163389124.27.8F4159B Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by imf26.hostedemail.com (Postfix) with ESMTP id 0C598140005 for ; Wed, 23 Nov 2022 04:14:01 +0000 (UTC) Received: by mail-pj1-f49.google.com with SMTP id t17so14228759pjo.3 for ; Tue, 22 Nov 2022 20:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3R5kXJm+KR5AiX1AMlOLzMKVuj1Y3Ygn0JJmuEOZJmQ=; b=IcZNfrgnIfrSdc0FW6pTw+GOdenTQ0AMdj4QQDRF8juwbMbOhL1zuSQD8SPdZGzMgv HNGnqJ5XNUpE3knxp9Tz+3QzOsZ+ALPtsHqerBWlb4ISDc/uNyXhwa8bz0Em/P3uwLzj Kn0dx8Dx9jpx8OHB2nl4mh2P5mq+yvQVsX8gw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3R5kXJm+KR5AiX1AMlOLzMKVuj1Y3Ygn0JJmuEOZJmQ=; b=mmpI4xTDrq5E6Sz/4bh541gEFSQz+4U80jjSNAYxM3gpfpSEHnros2IMAjjQhs1aPB i4Dt4pim98gC/+XukIW3MD98Lz0gvRV9kqOBZZMtExrw/nuBla7YzdFTKEeC3vmM+L8q JpWttjvhoDsgTbSeD4BvDES9MNSHDCalZ9X9IXPEQ7M9F38cigqBC7BDuH9Xgz3nKwKZ ECg85tJj7ZDZugm1Y7XiSGnxJ6yacLK8/04TOcK1NgPLTFgGQ1DCIggLVu/KEaIZf2Uv Q0E9yL+fCJemudWmPt29mgHFDlKMmE/9bZyFJQ4gzIIp/QEHSkfEJ76Bt1F+SbfKDBzH Jhdw== X-Gm-Message-State: ANoB5pkzW77sKSAr9luQExIfPvDYNdA+QXu3YG9IsJZjBGwzUi4fmUqs iPeeRmsCsvBfNS4TKSXILfy2Ow== X-Google-Smtp-Source: AA0mqf5j3OSa939puKpzv39BJknnN9wAwCiahUryDGlII3vo5W17YQ5PIAZOjXOH7jAU/DnQqFgWvg== X-Received: by 2002:a17:902:6847:b0:183:6555:38ef with SMTP id f7-20020a170902684700b00183655538efmr10593669pln.157.1669176840983; Tue, 22 Nov 2022 20:14:00 -0800 (PST) Received: from google.com ([240f:75:7537:3187:b570:e8d2:6522:6054]) by smtp.gmail.com with ESMTPSA id u15-20020a17090341cf00b0018930dbc560sm3096288ple.96.2022.11.22.20.13.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Nov 2022 20:14:00 -0800 (PST) Date: Wed, 23 Nov 2022 13:13:55 +0900 From: Sergey Senozhatsky To: Aleksey Romanov Cc: Sergey Senozhatsky , 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 Message-ID: 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: <20221122121413.ssieckg523urj37h@cab-wsm-0029881.lan> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669176842; a=rsa-sha256; cv=none; b=ceBiE3mOrkV6MK5PIjavfmlqSWZsC5xHxT5vjHcnW1r0HwmV340nCXN4fy7KYUm+kuZk4H c+WCZ52Q5GJCwMBBIsiVi6tiPXunM2KaOm78IS1sG3E/1pBz3PcC1IfDOsWIjHGrH5qQNM AuhIDEPwiMgm1ScmSnnURTTfsT5ik4I= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=IcZNfrgn; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf26.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.49 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669176842; 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=3R5kXJm+KR5AiX1AMlOLzMKVuj1Y3Ygn0JJmuEOZJmQ=; b=mKpCQC2wJetcnnA5YroWX33ytYJY6mt60KVTQ/CNvDV0euJHZtbZ/UlWVW8V4k0jexgkXG v9OoMkUtglvK16epBb/frhZ1P5IgWeIdujy97RGYmB8OaavdRijH5RN1fIHxPx9KB8UFfw 7F6PnRaxGNbH2gpGIN6Gbrd9nv1kcUU= X-Stat-Signature: a9ymce4sttcpoo856ncpfjskrb891cqb X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0C598140005 Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=IcZNfrgn; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf26.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.216.49 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org X-Rspam-User: X-HE-Tag: 1669176841-956587 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: 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.