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 6BD70C5478C for ; Wed, 28 Feb 2024 19:38:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ECA8E6B00A0; Wed, 28 Feb 2024 14:38:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E79F26B00A2; Wed, 28 Feb 2024 14:38:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D41666B00A3; Wed, 28 Feb 2024 14:38:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C232A6B00A0 for ; Wed, 28 Feb 2024 14:38:07 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9DD9BA1705 for ; Wed, 28 Feb 2024 19:38:07 +0000 (UTC) X-FDA: 81842223414.03.7CF173A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 5E6FA1C000A for ; Wed, 28 Feb 2024 19:38:01 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fw23fKiv; dmarc=none; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709149081; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3bitNwsNUQtvL4clG/gQllWxq/ktd5g1prsDm36+c7U=; b=GPGSqXvq+dgQ0JHXT9gcOq4uCVFONIj5z+9wKHINKe8ez1mXPYhsN10Ug7wcDTaq+fK24o EEehr5oQEl0UHzUaINgSv3LhwYoTQRMeMYW54vnQTGGLtzsHuRRjVwo+HV1UjkfQYu6VMO fEOY5wLvjW1YHc20u/rdOw0pJ79r7oc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fw23fKiv; dmarc=none; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709149081; a=rsa-sha256; cv=none; b=zt1EvXUx4MOX5gN6+BoMIDVa5fcu2esKnjTj7xtYENBN9tOviBQlSpEIpV49WutmHjrcSP slChZKF4/H5YIyIP4mvLBkwv8FvpwOoGqIEoZUcLktIJFX89GNYW/LLis6s3sBvWuSjwz9 hgsL8f1mZLR3PMAdiGVU0IFYzCgqTyo= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=3bitNwsNUQtvL4clG/gQllWxq/ktd5g1prsDm36+c7U=; b=fw23fKivUso0nrN7IX48yB2MFq v58/vrqI0g7FXF3hCKTBT34s7A0u3nwl7pwtMilLM/ntPnCg/TYwP6eYf1IAsleW2TKYbH7cveTTH JAqAWtRECINpOzrzU3CsISMJgJAwHNHQ7VuhvwuI5lrza5gieZtErg4r3c+rJZgXxACpFAGCi8rsl GzrTRxvIyD16O8/jJ91M7vpqK2idTNjK3Ypd/xu5zoIFEOc9MMJ1MIjaYQCyblju9K5g2zbCPzddh vCLH94yQNkqBa3YBkgiEvNelbCscBJ3pEZ5p6DIOWkXF1UB28ePZSCOEdY/wPvYpJy/ur8bf8jz+o hyXfCP8A==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rfPkc-000000061uw-0uvg; Wed, 28 Feb 2024 19:37:58 +0000 Date: Wed, 28 Feb 2024 19:37:58 +0000 From: Matthew Wilcox To: Amir Goldstein Cc: paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel , Kent Overstreet , Jan Kara Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Stat-Signature: axin6u1td495g6ozxiziwgascu5dsu3e X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5E6FA1C000A X-HE-Tag: 1709149081-200275 X-HE-Meta: U2FsdGVkX1+blfE0XnRVjcUtsPw89BJkUk7YsacmtQOytKLY5SlYSIFykS9z8lhigL4pKuHZmg4KXugkDJmM9nMRAulMtNdXJdDdQCUoisOhLdh72+2Nkm5FZegD1Vxb6A1UcsBX8ihr5W5CUTvzuKBJG4/BXBLDgPSvuoTSpCyXe6twSE6D4j0fKaQb8Sp+X3f9qpmA6P6WfneWfZNMnCxgU60ZWfvfmvNMKWBhsePsshhIjRSKVtIygqZYleH6XVkGAEOOK/rCoElqNFHtB1hHNYzSf8cdrGgvbHUM43ibNhjBCKNuS4r93Li3QXtoL/zqM7WTRr0o0cGCm7CArrtQ+iRnCQ11/ZYJqudsTVruvNBNWG2zL+/CDBs30ABFzul9QD2bCgtLLCkmxTZQTuUcHGU+f57NSk5mFet2AsoS77/yQD0QHfCvHyt7YB0l1R7VhVBcgAHVgdDE1+wtxhPaB9YwaxZlwZfB6Ut3P8joHKaIym1snnOaC+XwnFj0xETtvnxiDFCXdxvefxxlF1dKTbHTmwVIQSGAXdVo9g/D2jbeWp0327bA1wzsmJjf73q0mSriU6BqeZ2m+ny+F0OJPYetOVrUG11ZJ3p11kMz5hhcXbEHrCBb74XHC0/ZlJQF81SIBzBiygBB50a9PflJltOGuFchl7BL5QGzOHekATdrKtUmW7NjRkGHv0h+h9Bb7B0M0vi8RnrlJn1N5ivdwRmivAUBJ76BocQkO8Zjv9jJDOkr1/NQDL1+1U6ZltUcjHD/tJ8MjpI8fIIVtinYhQMh4q+7TfK+i6d7RnGAMTvWlgx7UWvjri2nSDfjVcSIB35skQ1sKFKwzeb+AA== 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: List-Subscribe: List-Unsubscribe: On Tue, Feb 27, 2024 at 09:19:47PM +0200, Amir Goldstein wrote: > On Tue, Feb 27, 2024 at 8:56 PM Paul E. McKenney wrote: > > > > Hello! > > > > Recent discussions [1] suggest that greater mutual understanding between > > memory reclaim on the one hand and RCU on the other might be in order. > > > > One possibility would be an open discussion. If it would help, I would > > be happy to describe how RCU reacts and responds to heavy load, along with > > some ways that RCU's reactions and responses could be enhanced if needed. > > > > Adding fsdevel as this should probably be a cross track session. Perhaps broaden this slightly. On the THP Cabal call we just had a conversation about the requirements on filesystems in the writeback path. We currently tell filesystem authors that the entire writeback path must avoid allocating memory in order to prevent deadlock (or use GFP_MEMALLOC). Is this appropriate? It's a lot of work to assure that writing pagecache back will not allocate memory in, eg, the network stack, the device driver, and any other layers the write must traverse. With the removal of ->writepage from vmscan, perhaps we can make filesystem authors lives easier by relaxing this requirement as pagecache should be cleaned long before we get to reclaiming it. I don't think there's anything to be done about swapping anon memory. We probably don't want to proactively write anon memory to swap, so by the time we're in ->swap_rw we really are low on memory.