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 X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A0E6C4332D for ; Wed, 17 Mar 2021 10:54:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E8F4F64F3C for ; Wed, 17 Mar 2021 10:54:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230468AbhCQKyL (ORCPT ); Wed, 17 Mar 2021 06:54:11 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:49880 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230204AbhCQKxx (ORCPT ); Wed, 17 Mar 2021 06:53:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615978433; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=CrP2lfrrdq12nJd/eCkP5MvOV60FCODOOLwLlbcHJdc=; b=Q+PE8T/ym9Kl+pAV26qBDs+PfSDDs+RAkqLZekmaTisCw+/zBPOE7f232pE+Un3cWQtgG6 k3MGX13m8vNCFy9JOCM9vsmhjbhmBchoGd8gM/Naw+vjvU1rOTXKgvVDQYK1ebzKA2FUno MCfejxn9uR+wi1gLIZrEPgvSYz3GA5g= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-149-YK1MK1d2OtGgyArc0_7DAQ-1; Wed, 17 Mar 2021 06:53:49 -0400 X-MC-Unique: YK1MK1d2OtGgyArc0_7DAQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7B60C84BA43; Wed, 17 Mar 2021 10:53:46 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-113-138.rdu2.redhat.com [10.10.113.138]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9D8CE6C32F; Wed, 17 Mar 2021 10:53:42 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <31382.1615971849@warthog.procyon.org.uk> References: <31382.1615971849@warthog.procyon.org.uk> <161539526152.286939.8589700175877370401.stgit@warthog.procyon.org.uk> <161539528910.286939.1252328699383291173.stgit@warthog.procyon.org.uk> <20210316190707.GD3420@casper.infradead.org> <887b9eb7-2764-3659-d0bf-6a034a031618@toxicpanda.com> To: Linus Torvalds Cc: dhowells@redhat.com, Josef Bacik , Matthew Wilcox , Chris Mason , David Sterba , Trond Myklebust , Anna Schumaker , Steve French , Dominique Martinet , Christoph Hellwig , Alexander Viro , Linux-MM , linux-cachefs@redhat.com, linux-afs@lists.infradead.org, "open list:NFS, SUNRPC, AND..." , CIFS , ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-fsdevel , Jeff Layton , David Wysochanski , Linux Kernel Mailing List Subject: Re: [PATCH v4 02/28] mm: Add an unlock function for PG_private_2/PG_fscache MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38367.1615978421.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Mar 2021 10:53:41 +0000 Message-ID: <38368.1615978421@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org David Howells wrote: > (1) For the old fscache code that I'm trying to phase out, it does not = take a > ref when PG_fscache is taken (probably incorrectly), relying instea= d on > releasepage, etc. getting called to strip the PG_fscache bit. PG_f= scache > is held for the lifetime of the page, indicating that fscache knows= about > it and might access it at any time (to write to the cache in the > background for example or to move pages around in the cache). > = > Here PG_fscache should not prevent page eviction or migration and i= t's > analogous to PG_private. > = > That said, the old fscache code keeps its own radix trees of pages = that > are undergoing write to the cache, so to allow a page to be evicted= , > releasepage and co. have to consult those > (__fscache_maybe_release_page()). Note that, ideally, we'll be able to remove the old fscache I/O code in th= e next merge window or the one after. David