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 6D5EDC433FE for ; Mon, 21 Nov 2022 20:44:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C1546B0072; Mon, 21 Nov 2022 15:44:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 971BE6B0073; Mon, 21 Nov 2022 15:44:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 839446B0074; Mon, 21 Nov 2022 15:44:28 -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 7088F6B0072 for ; Mon, 21 Nov 2022 15:44:28 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D2296C0897 for ; Mon, 21 Nov 2022 20:44:27 +0000 (UTC) X-FDA: 80158627374.27.16C8490 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf24.hostedemail.com (Postfix) with ESMTP id 35CD4180012 for ; Mon, 21 Nov 2022 20:44:27 +0000 (UTC) Received: by mail-qk1-f177.google.com with SMTP id z1so8901079qkl.9 for ; Mon, 21 Nov 2022 12:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; 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=ZLM4dQ8DfOCVp9j2Qcll4uaEz3VQYSBLl74/xIF32d8=; b=AM98z3cNsvRELUM5EESx6H5Jini6qLdvb10A63UmI0r9Zvp/b8oQbtmI3aZ7e7mSsZ e/GVMo3l2t93qmc9/t6brPu9ki4MVTauqEUdNsjNw/ejYm8W+xXbQjkjGfR9QDheyb20 aVJZ58rMX1X24kmJBaqderRGLaNMxyLabbGKcs1NVVeCRW1bifK2kK6BE2YFo0z7y+mB lD4ltYoyc4GFahO9p0Te/279AoiEvC73qizRw84n3QMJoE2jVdcBEy6A9KHjLXJvWs6I wJ8Xjc9YlKRhPq8jyk9jgEvivliKTb8QwC71iuu2mBYS9dfN3yAaLY/ekVjOyzNumZvo eW6w== 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=ZLM4dQ8DfOCVp9j2Qcll4uaEz3VQYSBLl74/xIF32d8=; b=Jw+SH7YuN2bKCdLjQxGejuNSPEwu6Lz+X5qTHX3FPodFPobnQ40RCQ6ya5JLo9ovqm lIX3CKmuM12+6fUiLAQ0vaGqDFEHjzyk7NPtFFOQRyy742ZynDLOudw51WfqM2kY65aB w+sKnEerdUKO4plpRQZtrH+scI8beTar4nQ3J6bThERrEh1W8723JoqMMjmoCfoE90TJ j15qF5/Te5udZJSbX/yc7qOOcAyGnJZ1if3Ln8ssZX4jbpU9js5D3cPWuMhl677PPkx5 Tcpr9h+xVsfotrQwacEMFsAbv2iYCZCB2PEbnwZnc9cOQXal9QkaonIxhHQ/GUxiuwTS y7cQ== X-Gm-Message-State: ANoB5pnB4Ew3hXjwmGPEx0Nlcw+2tamcvAsrm74Fm2m0wKPbiTyNUKXv coVvJgFJlpSSliu35tPQZzCExA== X-Google-Smtp-Source: AA0mqf4xzKPjIVvSosLQhXCKexOKlCvsdNagXLqURCTkkB6pZlsCkMfyz0dOj1UIOJLpTk7nANYa3w== X-Received: by 2002:a05:620a:16a7:b0:6ea:3fa0:bbfb with SMTP id s7-20020a05620a16a700b006ea3fa0bbfbmr1185226qkj.473.1669063466320; Mon, 21 Nov 2022 12:44:26 -0800 (PST) Received: from localhost ([2620:10d:c091:480::1:bc4]) by smtp.gmail.com with ESMTPSA id s7-20020a05620a254700b006fba44843a5sm9034117qko.52.2022.11.21.12.44.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 12:44:25 -0800 (PST) Date: Mon, 21 Nov 2022 15:44:51 -0500 From: Johannes Weiner To: Alexey Romanov Cc: 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: <20221121190020.66548-1-avromanov@sberdevices.ru> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669063467; a=rsa-sha256; cv=none; b=Dnpmd20Li2DNse+x905cpNsEKLdrPTgf76uawhiYcldhuSmS3uLPsTVWLyolzEr2nEjDMk XJXPpztbUO7xwI79N+S9pu2qz4oOuGlFRAAlYIqpxINn5QCPMPjgd+MBRXl+UChmFnyNwX jO+fmohjZ7RtBWbNg+9e9MzDDaGZf9M= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=AM98z3cN; spf=pass (imf24.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.177 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669063467; 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=ZLM4dQ8DfOCVp9j2Qcll4uaEz3VQYSBLl74/xIF32d8=; b=liC5p78p5HZCrb8tPDdu1qhPxMAc0uP5B6N2Rj9hNeXb7GiKkndcMy3Izz/udTptq5AtBh YhCoOF1EUYZuBM4nh89ZmSbuMCud1foHthcnhJ3CXeM1metXcAk3vNUw6N2fiqwqpqkaOs sodaEIdd+f6pXZs77p3r3w+1YE93hbM= X-Stat-Signature: qzai9dbum3rqhbogajfgcazsi93uy497 X-Rspamd-Queue-Id: 35CD4180012 X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=AM98z3cN; spf=pass (imf24.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.177 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Rspamd-Server: rspam02 X-HE-Tag: 1669063467-866095 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 Mon, Nov 21, 2022 at 10:00:16PM +0300, Alexey Romanov wrote: > Hello! > > This RFC series adds feature which allows merge identical > compressed pages into a single one. The main idea is that > zram only stores object references, which store the compressed > content of the pages. Thus, the contents of the zsmalloc objects > don't change in any way. > > For simplicity, let's imagine that 3 pages with the same content > got into zram: > > +----------------+ +----------------+ +----------------+ > |zram_table_entry| |zram_table_entry| |zram_table_entry| > +-------+--------+ +-------+--------+ +--------+-------+ > | | | > | handle (1) | handle (2) | handle (3) > +-------v--------+ +-------v---------+ +--------v-------+ > |zsmalloc object| |zsmalloc object | |zsmalloc object| > ++--------------++ +-+-------------+-+ ++--------------++ > +--------------+ +-------------+ +--------------+ > | buffer: "abc"| |buffer: "abc"| | buffer: "abc"| > +--------------+ +-------------+ +--------------+ > > As you can see, the data is duplicated. Merge mechanism saves > (after scanning objects) only one zsmalloc object. Here's > what happens ater the scan and merge: > > +----------------+ +----------------+ +----------------+ > |zram_table_entry| |zram_table_entry| |zram_tabl _entry| > +-------+--------+ +-------+--------+ +--------+-------+ > | | | > | handle (1) | handle (1) | handle (1) > | +--------v---------+ | > +-----------> zsmalloc object <-----------+ > +--+-------------+-+ > +-------------+ > |buffer: "abc"| > +-------------+ > > Thus, we reduced the amount of memory occupied by 3 times. > > This mechanism doesn't affect the perf of the zram itself in > any way (maybe just a little bit on the zram_free_page function). > In order to describe each such identical object, we (constantly) > need sizeof(zram_rbtree_node) bytes. So, for example, if the system > has 20 identical buffers with a size of 1024, the memory gain will be > (20 * 1024) - (1 * 1024 + sizeof(zram_rbtree_node)) = 19456 - > sizeof(zram_rbtree_node) bytes. But, it should be understood, these are > counts without zsmalloc data structures overhead. > > Testing on my system (8GB ram + 1 gb zram swap) showed that at high > loads, on average, when calling the merge mechanism, we can save > up to 15-20% of the memory usage. 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? > This patch serices adds a new sysfs node (trigger merging) and new > field in mm_stat (how many pages are merged in zram at the moment): > > $ cat /sys/block/zram/mm_stat > 431452160 332984392 339894272 0 339894272 282 0 51374 51374 0 > > $ echo 1 > /sys/block/zram/merge > > $ cat /sys/block/zram/mm_stat > 431452160 270376848 287301504 0 339894272 282 0 51374 51374 6593 The optimal frequency for calling this is probably tied to prevalent memory pressure, which is somewhat tricky to do from userspace. Would it make sense to hook this up to a shrinker?