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 9CE2AC433FE for ; Tue, 22 Nov 2022 03:00:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3767D6B0071; Mon, 21 Nov 2022 22:00:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 326D66B0073; Mon, 21 Nov 2022 22:00:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EE0B6B0074; Mon, 21 Nov 2022 22:00:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0B3986B0071 for ; Mon, 21 Nov 2022 22:00:43 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C2F6D80DAD for ; Tue, 22 Nov 2022 03:00:42 +0000 (UTC) X-FDA: 80159575524.04.3988132 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf25.hostedemail.com (Postfix) with ESMTP id 4C8B7A000E for ; Tue, 22 Nov 2022 03:00:42 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id jn7so10493551plb.13 for ; Mon, 21 Nov 2022 19:00:41 -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=wHFDUHtOwvUbApX56IPf0JK3BcogReTYpXne7oiLh6g=; b=HsHhTLxPGSX/SOQLa8i0mclVgaAony/uoIqSiNk2F7aUqm3oOvFR4+hqrJeWKeA8kP 0ev+UlYSci2yUYxBYTcHi/07bQFHH0vf5Pp6rNi78LMk6kGatA4cfPszA84RKTU0O+gA xwlHUTY52a76c0t0mqgbv+/6Yc8+9PpHYpKkI= 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=wHFDUHtOwvUbApX56IPf0JK3BcogReTYpXne7oiLh6g=; b=EGnnyiUNKBONmXxZd1S7WSyWB6fvv5Q8hPsBtH6321lBCQuRrMx03Qak9MO+RKAGbv LpEkSGx3Yqqnni2bET34Dz5/POUTAYMLKUlEgHCHrSWTzvfrWtVGunMOihtfD9fbxmUd GsxCNpzjEIKs+/60bA3e08k6hLZk1WI43QdfjP4dnFLIJpwVB/VzbnscdemRAeQ8DzR6 zsNs/cUyX+gPC7bXIAMZ743FZT46519FQFQQjWNygZJW8UPWyG+r/84F7a0W6HG2IUTI cpqOFxHnThihmzqdNbRKegfQTtaaTAlh0S1zaG3jWAd/Okq8d3immn52iVFsEnkSIQ+s ilfQ== X-Gm-Message-State: ANoB5pkBqFu+kkrl41/+YEhnRXjI4iGnx4397wCVfxWSrXiJFWNXcDLO sowpqnF/ueD1qzDFbmpIcnR1sQ== X-Google-Smtp-Source: AA0mqf6ssW5PeKYQMBjucgUacUesrALiKSjEBDiNYRmO/H0eoDAdfWODXNQS/1qb7eR9vXjF1Udllg== X-Received: by 2002:a17:902:6b89:b0:179:eaa8:9113 with SMTP id p9-20020a1709026b8900b00179eaa89113mr1725905plk.55.1669086041198; Mon, 21 Nov 2022 19:00:41 -0800 (PST) Received: from google.com ([240f:75:7537:3187:e258:71ac:37b7:2d52]) by smtp.gmail.com with ESMTPSA id a14-20020a170902710e00b0018703bf3ec9sm10525755pll.61.2022.11.21.19.00.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 19:00:40 -0800 (PST) Date: Tue, 22 Nov 2022 12:00:36 +0900 From: Sergey Senozhatsky To: Johannes Weiner Cc: Alexey Romanov , minchan@kernel.org, senozhatsky@chromium.org, ngupta@vflare.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@sberdevices.ru, ddrokosov@sberdevices.ru Subject: Re: [RFC PATCH v1 0/4] Introduce merge identical pages mechanism Message-ID: References: <20221121190020.66548-1-avromanov@sberdevices.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669086042; a=rsa-sha256; cv=none; b=3t7W4zusYdmjzyuH/1QnTPkYCKtdvgafQyaLjeGr+DsAECU8Z4jU6Ge0O0yqqp9IgYHteV tZIwcYmlPEzx20BAk1Ma+ljbPghrpkcgNiGnsKvHVsxX59RyEuqc73OXXVdh34gPoZ2PhL reDzENK+tqXTTzOn+Lew+qde7kG5HlY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HsHhTLxP; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf25.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.175 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=1669086042; 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=wHFDUHtOwvUbApX56IPf0JK3BcogReTYpXne7oiLh6g=; b=J+DWZ+IGbyyuOmfnhReqUJAcs4v8L0eYyMp+aMouGKJIN8XRmnUa88YsLIN8+s72QkWB7t DW7HaJtA1a7NT6wvMKqHO/gpz22TQuPa/Gkj+QyQ1r3PFDUU182WMk4cqlHGN9LfeeGhWA scXRTqo6J7DyYcigIj7D1zBozcly5VE= Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=HsHhTLxP; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf25.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.214.175 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org X-Stat-Signature: kfutan6e8cf169joqbybeo74fhtwzm57 X-Rspamd-Queue-Id: 4C8B7A000E X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1669086042-275948 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000015, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On (22/11/21 15:44), Johannes Weiner wrote: > This looks pretty great. > > However, I'm curious why it's specific to zram, and not part of > zsmalloc? That way zswap would benefit as well, without having to > duplicate the implementation. This happened for example with > page_same_filled() and zswap_is_page_same_filled(). > > It's zsmalloc's job to store content efficiently, so couldn't this > feature (just like the page_same_filled one) be an optimization that > zsmalloc does transparently for all its users? Yea, that's a much needed functionality, but things may be "complicated". We had that KSM-ish thing in the past in zram. Very briefly as we quickly found out that the idea was patented by some company in China and we couldn't figure our if it was safe to land that code upstream. So we ended up dropping the patches. https://lore.kernel.org/lkml/1494556204-25796-1-git-send-email-iamjoonsoo.kim@lge.com/ > Would it make sense to hook this up to a shrinker? Hmm, ratelimited perhaps. We most likely don't want to scan the whole pool every time a shrinker calls us (which can be quite often).