Message ID | 20230606145611.704392-1-cerasuolodomenico@gmail.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp3490593vqr; Tue, 6 Jun 2023 08:45:42 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ73Azij4XZH+85w9G89ri1dBWAAszmX/cFTb+BOMB+5T27HMc2LnFnw2+Hp4Annj1zjKvc5 X-Received: by 2002:a05:620a:3187:b0:75d:17d4:8462 with SMTP id bi7-20020a05620a318700b0075d17d48462mr54663qkb.45.1686066342193; Tue, 06 Jun 2023 08:45:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686066342; cv=none; d=google.com; s=arc-20160816; b=FeIKIf1UqrZuiQZBjIBCA9gJIjS7m4YwET6c7clWciMzE5mKJC9iqPB6qTLPJEudhe nw4hWPQ2uiFLPK3I6CEZtVaq/auv+CQgfy2bQebu7uEzJYOHOuN/v9i85MKxmA9/BaN2 E6JYvS8Ox3RQOjG8XIJ3U5EkOF+QfSxczU5gk39eMDZPK2jZ8v+ZIkH27gfcMdk7rVfB gP6+OCZatptfoPV3iC/4IZmd9AVyxdvEtOEygjU8EYXc2mfgAulkYIAgM/DrgpSkTGtx Gc+8VwY7Ovu4syor7ZY1r4JiDMyZaacrcWn7U6VxecRSv2vDSt4ktmP4n4OSuIt/Twdl b5IA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=mynbaLKp576BHmSfRlc0g7QtomnRapZLg6iYg51c7rM=; b=C61rndljyGyNlWTTlE8r6nyb/b4+g26oiN8DZNKqOPpqDMu+SUWUEmN5YpZCKKfcLK kVZzrGVO2/OUHDhv0Rk7Cl/x4pjCWMu72lUYp4gugkS5lgOAy49vqq4r2kzMvi+l8JQS +RpXxcWkJxwlupRoQL+3pyAGrxI0d00ryZCyGYqvU4jyJlhwhi6WJr8/28fMX5Auq/D9 y6E7vi3t/tqYmFkw7Q5F8nFaQA9XoQBwMKMhsnU6ttUR4uXoi+ND6wy2YGaUgq9Awmtw lcM8v3KKTkgDxh0lDZolmgQhaHpBUu4HmyLZTQB04Og7Tz6tQK1fGcWBNfZZkAl+8yh2 +aHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=HZFfeto2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w20-20020a05620a129400b0074fc1cfb2c9si6022314qki.685.2023.06.06.08.45.28; Tue, 06 Jun 2023 08:45:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=HZFfeto2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238455AbjFFO5p (ORCPT <rfc822;xxoosimple@gmail.com> + 99 others); Tue, 6 Jun 2023 10:57:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60330 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237330AbjFFO5A (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 6 Jun 2023 10:57:00 -0400 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E2B71722 for <linux-kernel@vger.kernel.org>; Tue, 6 Jun 2023 07:56:38 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-977ed383b8aso267584266b.3 for <linux-kernel@vger.kernel.org>; Tue, 06 Jun 2023 07:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686063397; x=1688655397; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=mynbaLKp576BHmSfRlc0g7QtomnRapZLg6iYg51c7rM=; b=HZFfeto2Hpkc8haUjf586/zizHwIWfxy54etAJ8opWaDiMrtkcozh2lhBj2GJ5Csqp s380xukhPMxOUdUMrzVqiGBEmqz9peeNS9eCFS1CqT1EH1sPedvXMsU23QTDY9qV0ZbQ OIpfZd4BHw7WI0mD8CD9zAi16IywuEYet6eN6X+nNTZu896ay/a57WTBwC/1762uZfQq p8GY+HAi6gzLIw9YAB6suWiJ2KNp8Y9T5HaFDvVIGlk/s83l0Xy6pdHP10ykOoTodOVr Z2H8aKyl9FDoK11m3xIMZiqkkRYIPWL6m/1rRmm5frE7Bxcskqxk5XEZ5D7IaxbGOJTl p7oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686063397; x=1688655397; 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=mynbaLKp576BHmSfRlc0g7QtomnRapZLg6iYg51c7rM=; b=jkxK/+ZrfLeOfzH8vED8D6niE8gMsECTV250p6q5Uu37XjA0DSLdFZj2cBznX7kQnf nAVnXWwRvYcnxFG67OEpKSoq+lI674wtuLHlqd9UP67nGkOrlCQQIsqPXaarCjKLc6Rg yUzISRwxyfDJRLEAtUHrLnwZlGKC+cRi9EYHjE6tWyJvpHWtNjhBnZ1UvvGrOneLqFvm qhyJJPlThJe9sDBrw9bopnDKtVWtRgGR2qoVDDZvx5NFCvH550Sbw8BROHjPh6AUHEaO YAKnZ1bUqngqeJfne7prE3PHLoLnGCgwqh/oQDpgoPHWX0cwEH2+sO+P2ryaKrzNRoPE X5Gg== X-Gm-Message-State: AC+VfDyA4PQOOEoQTJ+gCciGCH/uBHyFP/J/W+RgfK0p8bvN0cSxZ/O+ edCZWOdcoOpOglZqfmwt5nA= X-Received: by 2002:a17:907:7da4:b0:974:1c98:d38e with SMTP id oz36-20020a1709077da400b009741c98d38emr2902003ejc.2.1686063396590; Tue, 06 Jun 2023 07:56:36 -0700 (PDT) Received: from lelloman-5950.homenet.telecomitalia.it (host-82-53-214-132.retail.telecomitalia.it. [82.53.214.132]) by smtp.gmail.com with ESMTPSA id t15-20020a1709063e4f00b00965c529f103sm5619618eji.86.2023.06.06.07.56.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jun 2023 07:56:36 -0700 (PDT) From: Domenico Cerasuolo <cerasuolodomenico@gmail.com> To: vitaly.wool@konsulko.com, minchan@kernel.org, senozhatsky@chromium.org, yosryahmed@google.com, linux-mm@kvack.org Cc: ddstreet@ieee.org, sjenning@redhat.com, nphamcs@gmail.com, hannes@cmpxchg.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Domenico Cerasuolo <cerasuolodomenico@gmail.com> Subject: [RFC PATCH v2 0/7] mm: zswap: move writeback LRU from zpool to zswap Date: Tue, 6 Jun 2023 16:56:04 +0200 Message-Id: <20230606145611.704392-1-cerasuolodomenico@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767968700760491775?= X-GMAIL-MSGID: =?utf-8?q?1767968700760491775?= |
Series |
mm: zswap: move writeback LRU from zpool to zswap
|
|
Message
Domenico Cerasuolo
June 6, 2023, 2:56 p.m. UTC
This series aims to improve the zswap reclaim mechanism by reorganizing the LRU management. In the current implementation, the LRU is maintained within each zpool driver, resulting in duplicated code across the three drivers. The proposed change consists in moving the LRU management from the individual implementations up to the zswap layer. The primary objective of this refactoring effort is to simplify the codebase. By unifying the reclaim loop and consolidating LRU handling within zswap, we can eliminate redundant code and improve maintainability. Additionally, this change enables the reclamation of stored pages in their actual LRU order. Presently, the zpool drivers link backing pages in an LRU, causing compressed pages with different LRU positions to be written back simultaneously. The series consists of several patches. The first patch implements the LRU and the reclaim loop in zswap, but it is not used yet because all three driver implementations are marked as zpool_evictable. The following three commits modify each zpool driver to be not zpool_evictable, allowing the use of the reclaim loop in zswap. As the drivers removed their shrink functions, the zpool interface is then trimmed by removing zpool_evictable, zpool_ops, and zpool_shrink. Finally, the code in zswap is further cleaned up by simplifying the writeback function and removing the now unnecessary zswap_header. Based on mm-stable + commit 399ab221f3ff ("mm: zswap: shrink until can accept") currently in mm-unstable. V2: - fixed lru list init/del/del_init (Johannes) - renamed pool.lock to lru_lock and added lock ordering comment (Yosry) - trimmed zsmalloc even more (Johannes | Nhat) - moved ref drop out of writeback function (Johannes) Domenico Cerasuolo (7): mm: zswap: add pool shrinking mechanism mm: zswap: remove page reclaim logic from zbud mm: zswap: remove page reclaim logic from z3fold mm: zswap: remove page reclaim logic from zsmalloc mm: zswap: remove shrink from zpool interface mm: zswap: simplify writeback function mm: zswap: remove zswap_header include/linux/zpool.h | 19 +- mm/z3fold.c | 249 +------------------------- mm/zbud.c | 167 +----------------- mm/zpool.c | 48 +---- mm/zsmalloc.c | 396 ++---------------------------------------- mm/zswap.c | 186 +++++++++++--------- 6 files changed, 130 insertions(+), 935 deletions(-)
Comments
On Tue, Jun 6, 2023 at 7:56 AM Domenico Cerasuolo <cerasuolodomenico@gmail.com> wrote: > > This series aims to improve the zswap reclaim mechanism by reorganizing > the LRU management. In the current implementation, the LRU is maintained > within each zpool driver, resulting in duplicated code across the three > drivers. The proposed change consists in moving the LRU management from > the individual implementations up to the zswap layer. > > The primary objective of this refactoring effort is to simplify the > codebase. By unifying the reclaim loop and consolidating LRU handling > within zswap, we can eliminate redundant code and improve > maintainability. Additionally, this change enables the reclamation of > stored pages in their actual LRU order. Presently, the zpool drivers > link backing pages in an LRU, causing compressed pages with different > LRU positions to be written back simultaneously. > > The series consists of several patches. The first patch implements the > LRU and the reclaim loop in zswap, but it is not used yet because all > three driver implementations are marked as zpool_evictable. > The following three commits modify each zpool driver to be not > zpool_evictable, allowing the use of the reclaim loop in zswap. > As the drivers removed their shrink functions, the zpool interface is > then trimmed by removing zpool_evictable, zpool_ops, and zpool_shrink. > Finally, the code in zswap is further cleaned up by simplifying the > writeback function and removing the now unnecessary zswap_header. > > Based on mm-stable + commit 399ab221f3ff > ("mm: zswap: shrink until can accept") currently in mm-unstable. I tested this + commit fe1d1f7d0fb5 ("mm: zswap: support exclusive loads") currently in mm-unstable, using zsmalloc and CONFIG_ZSWAP_EXCLUSIVE_LOADS=y. I only ran basic zswap tests with manual writeback induction and made sure everything is sane. I obviously hope you did more involved testing :) The only problem I came across is the conflict with fe1d1f7d0fb5, and I suggested the fix in patch 1. With the fix, everything seems correct. So I guess, FWIW for all the patches except 2 & 3 (for zbud and z3fold): Tested-by: Yosry Ahmed <yosryahmed@google.com> > > V2: > - fixed lru list init/del/del_init (Johannes) > - renamed pool.lock to lru_lock and added lock ordering comment (Yosry) > - trimmed zsmalloc even more (Johannes | Nhat) > - moved ref drop out of writeback function (Johannes) > > Domenico Cerasuolo (7): > mm: zswap: add pool shrinking mechanism > mm: zswap: remove page reclaim logic from zbud > mm: zswap: remove page reclaim logic from z3fold > mm: zswap: remove page reclaim logic from zsmalloc > mm: zswap: remove shrink from zpool interface > mm: zswap: simplify writeback function > mm: zswap: remove zswap_header > > include/linux/zpool.h | 19 +- > mm/z3fold.c | 249 +------------------------- > mm/zbud.c | 167 +----------------- > mm/zpool.c | 48 +---- > mm/zsmalloc.c | 396 ++---------------------------------------- > mm/zswap.c | 186 +++++++++++--------- > 6 files changed, 130 insertions(+), 935 deletions(-) > > -- > 2.34.1 >
On Wed, Jun 7, 2023 at 11:16 AM Yosry Ahmed <yosryahmed@google.com> wrote: > > On Tue, Jun 6, 2023 at 7:56 AM Domenico Cerasuolo > <cerasuolodomenico@gmail.com> wrote: > > > > This series aims to improve the zswap reclaim mechanism by reorganizing > > the LRU management. In the current implementation, the LRU is maintained > > within each zpool driver, resulting in duplicated code across the three > > drivers. The proposed change consists in moving the LRU management from > > the individual implementations up to the zswap layer. > > > > The primary objective of this refactoring effort is to simplify the > > codebase. By unifying the reclaim loop and consolidating LRU handling > > within zswap, we can eliminate redundant code and improve > > maintainability. Additionally, this change enables the reclamation of > > stored pages in their actual LRU order. Presently, the zpool drivers > > link backing pages in an LRU, causing compressed pages with different > > LRU positions to be written back simultaneously. > > > > The series consists of several patches. The first patch implements the > > LRU and the reclaim loop in zswap, but it is not used yet because all > > three driver implementations are marked as zpool_evictable. > > The following three commits modify each zpool driver to be not > > zpool_evictable, allowing the use of the reclaim loop in zswap. > > As the drivers removed their shrink functions, the zpool interface is > > then trimmed by removing zpool_evictable, zpool_ops, and zpool_shrink. > > Finally, the code in zswap is further cleaned up by simplifying the > > writeback function and removing the now unnecessary zswap_header. > > > > Based on mm-stable + commit 399ab221f3ff > > ("mm: zswap: shrink until can accept") currently in mm-unstable. > > I tested this + commit fe1d1f7d0fb5 ("mm: zswap: support exclusive > loads") currently in mm-unstable, using zsmalloc and > CONFIG_ZSWAP_EXCLUSIVE_LOADS=y. I only ran basic zswap tests with > manual writeback induction and made sure everything is sane. I > obviously hope you did more involved testing :) > > The only problem I came across is the conflict with fe1d1f7d0fb5, and > I suggested the fix in patch 1. With the fix, everything seems > correct. > > So I guess, FWIW for all the patches except 2 & 3 (for zbud and z3fold): > Tested-by: Yosry Ahmed <yosryahmed@google.com> Thanks a lot for the effort! I'll rebase and test it again before submitting the new version. > > > > > V2: > > - fixed lru list init/del/del_init (Johannes) > > - renamed pool.lock to lru_lock and added lock ordering comment (Yosry) > > - trimmed zsmalloc even more (Johannes | Nhat) > > - moved ref drop out of writeback function (Johannes) > > > > Domenico Cerasuolo (7): > > mm: zswap: add pool shrinking mechanism > > mm: zswap: remove page reclaim logic from zbud > > mm: zswap: remove page reclaim logic from z3fold > > mm: zswap: remove page reclaim logic from zsmalloc > > mm: zswap: remove shrink from zpool interface > > mm: zswap: simplify writeback function > > mm: zswap: remove zswap_header > > > > include/linux/zpool.h | 19 +- > > mm/z3fold.c | 249 +------------------------- > > mm/zbud.c | 167 +----------------- > > mm/zpool.c | 48 +---- > > mm/zsmalloc.c | 396 ++---------------------------------------- > > mm/zswap.c | 186 +++++++++++--------- > > 6 files changed, 130 insertions(+), 935 deletions(-) > > > > -- > > 2.34.1 > >
On Wed, Jun 7, 2023 at 2:24 AM Domenico Cerasuolo <cerasuolodomenico@gmail.com> wrote: > > On Wed, Jun 7, 2023 at 11:16 AM Yosry Ahmed <yosryahmed@google.com> wrote: > > > > On Tue, Jun 6, 2023 at 7:56 AM Domenico Cerasuolo > > <cerasuolodomenico@gmail.com> wrote: > > > > > > This series aims to improve the zswap reclaim mechanism by reorganizing > > > the LRU management. In the current implementation, the LRU is maintained > > > within each zpool driver, resulting in duplicated code across the three > > > drivers. The proposed change consists in moving the LRU management from > > > the individual implementations up to the zswap layer. > > > > > > The primary objective of this refactoring effort is to simplify the > > > codebase. By unifying the reclaim loop and consolidating LRU handling > > > within zswap, we can eliminate redundant code and improve > > > maintainability. Additionally, this change enables the reclamation of > > > stored pages in their actual LRU order. Presently, the zpool drivers > > > link backing pages in an LRU, causing compressed pages with different > > > LRU positions to be written back simultaneously. > > > > > > The series consists of several patches. The first patch implements the > > > LRU and the reclaim loop in zswap, but it is not used yet because all > > > three driver implementations are marked as zpool_evictable. > > > The following three commits modify each zpool driver to be not > > > zpool_evictable, allowing the use of the reclaim loop in zswap. > > > As the drivers removed their shrink functions, the zpool interface is > > > then trimmed by removing zpool_evictable, zpool_ops, and zpool_shrink. > > > Finally, the code in zswap is further cleaned up by simplifying the > > > writeback function and removing the now unnecessary zswap_header. > > > > > > Based on mm-stable + commit 399ab221f3ff > > > ("mm: zswap: shrink until can accept") currently in mm-unstable. > > > > I tested this + commit fe1d1f7d0fb5 ("mm: zswap: support exclusive > > loads") currently in mm-unstable, using zsmalloc and > > CONFIG_ZSWAP_EXCLUSIVE_LOADS=y. I only ran basic zswap tests with > > manual writeback induction and made sure everything is sane. I > > obviously hope you did more involved testing :) > > > > The only problem I came across is the conflict with fe1d1f7d0fb5, and > > I suggested the fix in patch 1. With the fix, everything seems > > correct. > > > > So I guess, FWIW for all the patches except 2 & 3 (for zbud and z3fold): > > Tested-by: Yosry Ahmed <yosryahmed@google.com> > > Thanks a lot for the effort! I'll rebase and test it again before submitting the > new version. Perhaps give v2 a little bit more time to give other folks a chance to take a look as well, save yourself (and probably Andrew) the trouble of sending a new version for every single review :) > > > > > > > > > V2: > > > - fixed lru list init/del/del_init (Johannes) > > > - renamed pool.lock to lru_lock and added lock ordering comment (Yosry) > > > - trimmed zsmalloc even more (Johannes | Nhat) > > > - moved ref drop out of writeback function (Johannes) > > > > > > Domenico Cerasuolo (7): > > > mm: zswap: add pool shrinking mechanism > > > mm: zswap: remove page reclaim logic from zbud > > > mm: zswap: remove page reclaim logic from z3fold > > > mm: zswap: remove page reclaim logic from zsmalloc > > > mm: zswap: remove shrink from zpool interface > > > mm: zswap: simplify writeback function > > > mm: zswap: remove zswap_header > > > > > > include/linux/zpool.h | 19 +- > > > mm/z3fold.c | 249 +------------------------- > > > mm/zbud.c | 167 +----------------- > > > mm/zpool.c | 48 +---- > > > mm/zsmalloc.c | 396 ++---------------------------------------- > > > mm/zswap.c | 186 +++++++++++--------- > > > 6 files changed, 130 insertions(+), 935 deletions(-) > > > > > > -- > > > 2.34.1 > > >