From patchwork Tue Oct 18 04:55:24 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergey Senozhatsky X-Patchwork-Id: 13009901 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 780B7C4332F for ; Tue, 18 Oct 2022 04:55:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A16006B0072; Tue, 18 Oct 2022 00:55:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9C5796B0075; Tue, 18 Oct 2022 00:55:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C1326B0078; Tue, 18 Oct 2022 00:55:43 -0400 (EDT) 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 7E9236B0072 for ; Tue, 18 Oct 2022 00:55:43 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 55B1B1A08F9 for ; Tue, 18 Oct 2022 04:55:43 +0000 (UTC) X-FDA: 80032857366.03.68A3123 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf10.hostedemail.com (Postfix) with ESMTP id ECC2FC0020 for ; Tue, 18 Oct 2022 04:55:42 +0000 (UTC) Received: by mail-pf1-f172.google.com with SMTP id p14so13051154pfq.5 for ; Mon, 17 Oct 2022 21:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=w5tX9Wl81PhQGUCZyqodqMuBbo62lHvN02l/1DnN1CY=; b=lBUzF0qSP6OCY8LpeWHglSg+CFL48y3RuTSeZ1O4eOctBVERnsUQPOZCfSaOXx2FFe 6sXFlLoCtPEmPSWnC9OsSS7FGu07HJG4ZRp6Z/t+un8YwAf3mWQ24BeJySA9IYqkIhzd xhKQv/2Dn1DIJGGN9jrRpHKuODXVuDYHvsqdQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=w5tX9Wl81PhQGUCZyqodqMuBbo62lHvN02l/1DnN1CY=; b=A+ROAVRHGu0GIlKDwdZaYbQtpjrvYVmyrb8/4iZvn0ppLZsbDUAlKmg9ssKSkkb3Wk gXpxvYQovLWK0Pae0D1iCLqrFv89+9AxzJapc18nCqgVc7OGznz+JmaIJRusrWkjsuv/ 2Ao4DbzaG/v9HDFSeoM7S2FSvKTKVu7rDrwi2faydiTTojagPhhD90uL877XQGHyZQR2 SdiSb5ele9s4f1dewy34z24lZpciPw3ylTgnRKcecxU8R6l31ji+TB0vHML7Q51wEqqA 4mkuV0JUci1DqNDwnITltNZLlq8MNlUXqAnD6Xanlldum8FfN0ykAfJPnO7s1IhLqXJT FNIw== X-Gm-Message-State: ACrzQf1weFkzBkxaJDDVE8zdabNWKd86c1+a16wNh6Dk4EvMmEuHAtZD t0EEMy8s1t4k5ox+jijYHKOXcg== X-Google-Smtp-Source: AMsMyM5Wd89HmV/5Tx932iiSrIAAnLk4MrkQ59yCklu8Av5H3hJIDUephSs5/6hnLkdJMaJ15l72Aw== X-Received: by 2002:a05:6a00:1406:b0:565:dc13:bb36 with SMTP id l6-20020a056a00140600b00565dc13bb36mr1386294pfu.46.1666068941843; Mon, 17 Oct 2022 21:55:41 -0700 (PDT) Received: from tigerii.tok.corp.google.com ([2401:fa00:8f:203:17a9:73b0:c262:eccd]) by smtp.gmail.com with ESMTPSA id p4-20020a170902e74400b0017b69f99321sm7549220plf.219.2022.10.17.21.55.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Oct 2022 21:55:41 -0700 (PDT) From: Sergey Senozhatsky To: Andrew Morton , Minchan Kim Cc: Nitin Gupta , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sergey Senozhatsky Subject: [PATCHv4 0/9] zram: Support multiple compression streams Date: Tue, 18 Oct 2022 13:55:24 +0900 Message-Id: <20221018045533.2396670-1-senozhatsky@chromium.org> X-Mailer: git-send-email 2.38.0.413.g74048e4d9e-goog MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666068943; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=w5tX9Wl81PhQGUCZyqodqMuBbo62lHvN02l/1DnN1CY=; b=aBlN/t1SaaBNt+ZhN54JtUD+86YhQm2jeleRGHt2kRArta+vETaDEVWZk9p5HBMemXI9QI A5Pj+qwe+GJc2vSYrkZu7xT/ujqw+JqDOQgsIIRPsZgKiuL9uxCC3sgjysQVPWBa5vCAac fZhdLr0150cyOxIh0Rf2lW9CEVGHA0w= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=lBUzF0qS; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf10.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.172 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666068943; a=rsa-sha256; cv=none; b=uaZot7exHGktcaURBxnShvJwJTGHD26Ldi1P+p8X3DRZU3T8m3yG1oRCbq239c0See+7H8 OLYA99UckFBibDkaJW/skjzJrpp2IivN/q6R3zIykkdSSO40ljvC//cbOxsnKoRMLWrh3Y RvxyZj6IpDpf27faSNUMwEpLrsdnleI= Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=lBUzF0qS; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf10.hostedemail.com: domain of senozhatsky@chromium.org designates 209.85.210.172 as permitted sender) smtp.mailfrom=senozhatsky@chromium.org X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: ECC2FC0020 X-Rspam-User: X-Stat-Signature: 8aar97oh6g9tjqw5xx9ip9p43ak38pt1 X-HE-Tag: 1666068942-981079 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, This series adds support for multiple (per-CPU) compression streams (at point only 2). The main idea is that different compression algorithms have different characteristics and zram may benefit when it uses a combination of algorithms: a default algorithm that is faster but have lower compression rate and a secondary algorithm that can use higher compression rate at a price of slower compression/decompression. There are several use-case for this functionality: - huge pages re-compression: zstd or deflate can successfully compress huge pages (~50% of huge pages on my synthetic ChromeOS tests), IOW pages that lzo was not able to compress. - idle pages re-compression: idle/cold pages sit in the memory and we may reduce zsmalloc memory usage if we recompress those idle pages. User-space has a number of ways to control the behavior and impact of zram recompression: what type of pages should be recompressed, size watermarks, etc. Please refer to documentation patch. v4: -- added IS_ERR_VALUE patch (Andrew) -- documented SIZE units (bytes) (Andrew) -- re-phrased writeback BIO error comment (Andrew) -- return zs_malloc() error code from zram_recompress() -- do not lose zram_recompress() error in recompress_store() -- corrected a typo -- fixed previous rebase errors -- rebased the series v3: -- conditionally reschedule during recompression loop so that we don't stall RCU grace periods -- fixed a false-positive WARN_ON v2: -- rebased -- mark completely incompressible pages (neither default nor secondary algorithm can compress them) with a new flag so that we don't attempt to recompress them all the time Sergey Senozhatsky (9): zram: Preparation for multi-zcomp support zram: Add recompression algorithm sysfs knob zram: Factor out WB and non-WB zram read functions zram: Introduce recompress sysfs knob documentation: Add recompression documentation zram: Add recompression algorithm choice to Kconfig zram: Add recompress flag to read_block_state() zram: Clarify writeback_store() comment zram: Use IS_ERR_VALUE() to check for zs_malloc() errors Documentation/admin-guide/blockdev/zram.rst | 64 ++- drivers/block/zram/Kconfig | 55 +++ drivers/block/zram/zcomp.c | 6 +- drivers/block/zram/zcomp.h | 2 +- drivers/block/zram/zram_drv.c | 458 +++++++++++++++++--- drivers/block/zram/zram_drv.h | 16 +- 6 files changed, 526 insertions(+), 75 deletions(-)