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 965CFC433EF for ; Sat, 25 Dec 2021 10:36:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C46C86B0071; Sat, 25 Dec 2021 05:36:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BF6676B0072; Sat, 25 Dec 2021 05:36:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABDFE6B0073; Sat, 25 Dec 2021 05:36:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id 9BE1B6B0071 for ; Sat, 25 Dec 2021 05:36:06 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 228398249980 for ; Sat, 25 Dec 2021 10:36:06 +0000 (UTC) X-FDA: 78955961532.06.67B104D Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by imf24.hostedemail.com (Postfix) with ESMTP id 60C19180044 for ; Sat, 25 Dec 2021 10:36:00 +0000 (UTC) Received: by mail-ua1-f44.google.com with SMTP id p2so18673041uad.11 for ; Sat, 25 Dec 2021 02:36:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WSqSuMuP1GC9zuDtXwCcS1k5lJH6Ajg56eS0dRt9IM8=; b=YAbr/dY5iLFwNDL1V8yfQNhdVdqdUtrmJIKTmHeUlq4T4Q5ZsIWE6vFueJd4vYZG8X MQeAR9n1OJcCmGrt8ttSFQ0kIVy5GynFkdOSxsEveckw2u3eRIA3hxyrQ/wx8BcYaANA bIpHxI6ebEsH77tVO/c25wg61lhspsxiEC5/nfoB5qGg790OMylAlOKkV5EKPgAAB26S 2NKdzY9MrTiAHfkXw+DksSYNgDfOs5STIsEFIIUI5jt0epgJ8zAolfTbsACxzzmxPCmL cj8ZEK4Xn+O20iqJ4lPKvA4QOrU+l42zOGBdHKncQdEiFTeY3kvNJ37zqh0Hklp8DBXV j4pQ== X-Gm-Message-State: AOAM5323pXGcsEixlXjP8Xpp/gU4a2MbPvqiY2gT/Jp0pSgp7RhvlT9C fYy84VWyIIIfw+1OoZUtbcH4VmV/JU+M6g== X-Google-Smtp-Source: ABdhPJxQb4f9Yo8rSWM8HgYlB+d6ViKpBM5UO2G6sPPmSFEGxW9ehp4i64eQUYtXmcz2WoinZ6DqkA== X-Received: by 2002:a05:6102:b15:: with SMTP id b21mr1814202vst.1.1640428564640; Sat, 25 Dec 2021 02:36:04 -0800 (PST) Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com. [209.85.222.46]) by smtp.gmail.com with ESMTPSA id d16sm1846923vsl.0.2021.12.25.02.36.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Dec 2021 02:36:04 -0800 (PST) Received: by mail-ua1-f46.google.com with SMTP id i5so3857801uaq.10 for ; Sat, 25 Dec 2021 02:36:04 -0800 (PST) X-Received: by 2002:a67:c81c:: with SMTP id u28mr2771847vsk.38.1640428563782; Sat, 25 Dec 2021 02:36:03 -0800 (PST) MIME-Version: 1.0 References: <20211224062246.1258487-1-hch@lst.de> <20211224062246.1258487-2-hch@lst.de> In-Reply-To: <20211224062246.1258487-2-hch@lst.de> From: Geert Uytterhoeven Date: Sat, 25 Dec 2021 11:35:52 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 01/13] mm: remove cleancache To: Christoph Hellwig Cc: Andrew Morton , Konrad Rzeszutek Wilk , Hugh Dickins , Seth Jennings , Dan Streetman , Vitaly Wool , Matthew Wilcox , Linux Kernel Mailing List , Linux FS Devel , Linux MM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 60C19180044 X-Stat-Signature: tih5kafy54szw3t49ci5cmoiiptwifko Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf24.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com X-HE-Tag: 1640428560-599719 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 Sat, Dec 25, 2021 at 2:41 AM Christoph Hellwig wrote: > The cleancache subsystem is unused since the removal of Xen tmem driver > in commit 814bbf49dcd0 ("xen: remove tmem driver"). > > Signed-off-by: Christoph Hellwig > arch/m68k/configs/amiga_defconfig | 1 - > arch/m68k/configs/apollo_defconfig | 1 - > arch/m68k/configs/atari_defconfig | 1 - > arch/m68k/configs/bvme6000_defconfig | 1 - > arch/m68k/configs/hp300_defconfig | 1 - > arch/m68k/configs/mac_defconfig | 1 - > arch/m68k/configs/multi_defconfig | 1 - > arch/m68k/configs/mvme147_defconfig | 1 - > arch/m68k/configs/mvme16x_defconfig | 1 - > arch/m68k/configs/q40_defconfig | 1 - > arch/m68k/configs/sun3_defconfig | 1 - > arch/m68k/configs/sun3x_defconfig | 1 - Although this would be removed during the next refresh anyway: Acked-by: Geert Uytterhoeven > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -444,28 +444,6 @@ config USE_PERCPU_NUMA_NODE_ID > config HAVE_SETUP_PER_CPU_AREA > bool > > -config CLEANCACHE > - bool "Enable cleancache driver to cache clean pages if tmem is present" > - help > - Cleancache can be thought of as a page-granularity victim cache > - for clean pages that the kernel's pageframe replacement algorithm > - (PFRA) would like to keep around, but can't since there isn't enough > - memory. So when the PFRA "evicts" a page, it first attempts to use > - cleancache code to put the data contained in that page into > - "transcendent memory", memory that is not directly accessible or > - addressable by the kernel and is of unknown and possibly > - time-varying size. And when a cleancache-enabled > - filesystem wishes to access a page in a file on disk, it first > - checks cleancache to see if it already contains it; if it does, > - the page is copied into the kernel and a disk access is avoided. > - When a transcendent memory driver is available (such as zcache or > - Xen transcendent memory), a significant I/O reduction > - may be achieved. When none is available, all cleancache calls > - are reduced to a single pointer-compare-against-NULL resulting > - in a negligible performance hit. > - > - If unsure, say Y to enable cleancache Ah, the joy of good advice... > - > config FRONTSWAP > bool "Enable frontswap to cache swap pages if tmem is present" > depends on SWAP Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds