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 512EEC4332F for ; Wed, 23 Nov 2022 20:26:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6190E6B0071; Wed, 23 Nov 2022 15:26:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A2D16B0072; Wed, 23 Nov 2022 15:26:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 469416B0074; Wed, 23 Nov 2022 15:26:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 358E46B0071 for ; Wed, 23 Nov 2022 15:26:16 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id ED53014126B for ; Wed, 23 Nov 2022 20:26:15 +0000 (UTC) X-FDA: 80165839110.12.CFC0B5B Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf19.hostedemail.com (Postfix) with ESMTP id 83F931A000D for ; Wed, 23 Nov 2022 20:26:15 +0000 (UTC) Received: by mail-qk1-f180.google.com with SMTP id v8so13265994qkg.12 for ; Wed, 23 Nov 2022 12:26:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CqmvkkESPfhDMe/qDmW4BJUOiTicPIv5an9zs8Gyv18=; b=H05YjYlWatbzx/wYDWLZlWtlE1KBwjnnlgWrAS57YeODNFQbfnbqnkGjrw+7lnDaor oScBBYPzE4yA/do2o0oXxJV/7PAgcLDU8MGXopXi7Hyz2CY8RYXjIOxuZIHXCxSyrV4d 4jeZ+ngrXKdb0oQJMIfkShcljtHyJ8LXyw7yk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CqmvkkESPfhDMe/qDmW4BJUOiTicPIv5an9zs8Gyv18=; b=CGfpbfSErQmgabAFN+8KfSTupZXsmO5/2k5FkEftqva/wabZd8710FF2KS/QDcTDrV xsAUuAbe9F2DkCtjQaBBEIFqSJOcotyPI0LFYrLNf9HF6VhDd3xZnlh7EiJO/kYCJ4og sDY6CS/VZKPnQJu9LtElibipM4LyEmtT9+mYmdJpSksq1CAmR1Sm/qBf99q7w90yLe0m V3Skpi3mcw3q0DHFD4OhEd56RT65KiTQ+10lIgUTJy7KGAQfo+RCT3fhG7FaBcBZsKEz 0AYoKWJ+7jX2sQvdCRF1gQo20I7J29L4pA0Apjvbq0+tqYCH5vA96ME3qPXj9a34ywGY FHeQ== X-Gm-Message-State: ANoB5pny3OrEPW3vhNP5/V6wP7o2fiKPOljJqxoHdL+/JT0IxjfAwzJ2 mNfNH2WTrh9DkMhAZdXchXKbAnzI98M5QA== X-Google-Smtp-Source: AA0mqf48kn4A+DS9HyEawIyWH2laPxPtjECnvXLp9uPRQjyDIqgBEqVnjhiT7Vby8WZqVwsfLRRHIQ== X-Received: by 2002:a05:620a:1b8e:b0:6fa:c61d:7512 with SMTP id dv14-20020a05620a1b8e00b006fac61d7512mr9148293qkb.408.1669235174024; Wed, 23 Nov 2022 12:26:14 -0800 (PST) Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com. [209.85.219.50]) by smtp.gmail.com with ESMTPSA id s7-20020a05620a254700b006fba44843a5sm12976284qko.52.2022.11.23.12.26.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Nov 2022 12:26:13 -0800 (PST) Received: by mail-qv1-f50.google.com with SMTP id n12so6861314qvr.11 for ; Wed, 23 Nov 2022 12:26:12 -0800 (PST) X-Received: by 2002:ad4:4101:0:b0:4b1:856b:4277 with SMTP id i1-20020ad44101000000b004b1856b4277mr10112261qvp.129.1669235172559; Wed, 23 Nov 2022 12:26:12 -0800 (PST) MIME-Version: 1.0 References: <1459152.1669208550@warthog.procyon.org.uk> <1619343.1669233783@warthog.procyon.org.uk> In-Reply-To: <1619343.1669233783@warthog.procyon.org.uk> From: Linus Torvalds Date: Wed, 23 Nov 2022 12:25:56 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] mm, netfs, fscache: Stop read optimisation when folio removed from pagecache To: David Howells Cc: willy@infradead.org, dwysocha@redhat.com, Rohith Surabattula , Steve French , Shyam Prasad N , Dominique Martinet , Ilya Dryomov , linux-cachefs@redhat.com, linux-cifs@vger.kernel.org, linux-afs@lists.infradead.org, v9fs-developer@lists.sourceforge.net, ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669235175; a=rsa-sha256; cv=none; b=wqhmsYRcQJZoRw+PMvNpOfdqRHwyy+E8nSRkNxknKS3e5m7fQCsRwW6IE9/SH06BTvfRZ1 /kaM7UAnAA/af333V2oyUjRZZE3l+Xerv3j+4dYi3GM/PaScOnuhPwKS6xgIc05MiFwyem I1Nvr4dkPX27I47yJHQioneaPrrRAHI= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=H05YjYlW; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.222.180 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669235175; 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=CqmvkkESPfhDMe/qDmW4BJUOiTicPIv5an9zs8Gyv18=; b=DBIX+oHMhRpTtftRjkw0hOmUsweK+dFvlgM2MQoVcPlc4PiPSz3E5b8HfSjiJ8X7UEqMzv GRybwLHSEqhbnCB+zZ8lKRlYtersBnvwINtTBOlsoayhlxmMhuttsqGLEITvFk/UpqwWgL p7XuFj/9FbQj0K7KeP1avgCDQj7xKCM= X-Stat-Signature: obc66f8q1f5j4ndigcgyi38j33emwcnk X-Rspamd-Queue-Id: 83F931A000D X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=H05YjYlW; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.222.180 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam02 X-HE-Tag: 1669235175-866455 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 Wed, Nov 23, 2022 at 12:03 PM David Howells wrote: > > Linus Torvalds wrote: > > > But I also think it's strange in another way, with that odd placement of > > > > mapping_clear_release_always(inode->i_mapping); > > > > at inode eviction time. That just feels very random. > > I was under the impression that a warning got splashed if unexpected > address_space flags were set when ->evict_inode() returned. I may be thinking > of page flags. If it doesn't, fine, this isn't required. I don't know if the warning happens or not, but the thing I reacted to was just how *random* this was. There was no logic to it, nor any explanation. I *suspect* that if we add this kind of new generic address space flag, then that flag should just be cleared by generic code when the address space is released. But I'm not saying it has to be done that way - I'm just saying that however it is done, please don't make it this random mess with no explanation. The *setting* of the flag was at least fairly obvious. I didn't find code like this odd: + if (v9inode->netfs.cache) + mapping_set_release_always(inode->i_mapping); and it makes all kinds of sense (ie I can read it as a "if I use netfs caching for this inode, then I want to be informed when a folio is released from this mapping"). It's just the clearing that looked very random to me. Maybe just a comment would have helped, but I get the feeling that it migth as well just be cleared in "clear_inode()" or something like that. > > That code makes no sense what-so-ever. Why isn't it using > > "folio_has_private()"? > > It should be, yes. > > > Why is this done as an open-coded - and *badly* so - version of > > !folio_needs_release() that you for some reason made private to mm/vmscan.c? > > Yeah, in retrospect, I should have put that in mm/internal.h. So if folio_needs_release() is in mm/internal.h, and then mm/filemap.c uses it in filemap_release_folio() instead of the odd open-coding, I think that would clear up my worries about both mm/filemap.c and mm/vmscan.c. Linus