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 DD1ADC48BF6 for ; Fri, 1 Mar 2024 02:16:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57CC76B0074; Thu, 29 Feb 2024 21:16:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 505106B0078; Thu, 29 Feb 2024 21:16:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 357A56B007E; Thu, 29 Feb 2024 21:16:30 -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 1D38B6B0074 for ; Thu, 29 Feb 2024 21:16:30 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C45CD140464 for ; Fri, 1 Mar 2024 02:16:29 +0000 (UTC) X-FDA: 81846856098.05.6E96658 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf17.hostedemail.com (Postfix) with ESMTP id 7B3B140012 for ; Fri, 1 Mar 2024 02:16:27 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ioxk4WSo; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=7q6cIrTX; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ioxk4WSo; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=7q6cIrTX; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf17.hostedemail.com: domain of neilb@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=neilb@suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709259387; 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=5cuFXdCHzzWXu0oiW3kPcFQ29IXMbiDarSwwKonCBIQ=; b=C5hPNXj0Ozg++JRckaLpGHnW66liOFHd9ABBGR5I+ZJmcqQtonaONWhVpbDYXuI1JnM55n wNSdQUVOxm6n5QZavucBPk9/rcITlYWw4iYuiWESmShdWoighu0YORa7WXjnNEdcgyLOg6 I3TjqoOGgGbE0PgHYwS7eWz4/LrvWok= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ioxk4WSo; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=7q6cIrTX; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=ioxk4WSo; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=7q6cIrTX; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf17.hostedemail.com: domain of neilb@suse.de designates 195.135.223.131 as permitted sender) smtp.mailfrom=neilb@suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709259387; a=rsa-sha256; cv=none; b=GltdgL59h7W4lkYimakgoM6nhXDjah8B9hiE8XdgQ6dG0MH4q5zbLzIPD+wDo/sWZWe5K9 ykYdLfI7vqyfRYajQ5HWpsEhACs4W+9Aq+NI412vZ2gC7cQzx18UcfZHonpc8ENAzrrcro oeMl8qpTVUnZndG9tsRmFV9GS9SAHgQ= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 824451F818; Fri, 1 Mar 2024 02:16:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1709259385; h=from:from:reply-to: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=5cuFXdCHzzWXu0oiW3kPcFQ29IXMbiDarSwwKonCBIQ=; b=ioxk4WSoH2rlOOnf0KU7f2FQM872F5hJ0A30+LdRWI2VOAxKVZbH0dfQPvkpVeuIyqzuxL S3dGWTQdtV7TcUWm7p+vtxZVcdwAVhXhrfR1MZ/godRPtgc1KZmHinZmDQhhMFiQodyrEX MGRB04NTWl46qPNW2Qk3fQ07RfMNjVQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1709259385; h=from:from:reply-to: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=5cuFXdCHzzWXu0oiW3kPcFQ29IXMbiDarSwwKonCBIQ=; b=7q6cIrTXGiXvpjazhjBjAqeZS6vB5FuKVy1OmPnyDHyTeWPPbAQIlwlB8ZZIOpjXRJFBQZ 9nP3JKktKbGnZqDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1709259385; h=from:from:reply-to: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=5cuFXdCHzzWXu0oiW3kPcFQ29IXMbiDarSwwKonCBIQ=; b=ioxk4WSoH2rlOOnf0KU7f2FQM872F5hJ0A30+LdRWI2VOAxKVZbH0dfQPvkpVeuIyqzuxL S3dGWTQdtV7TcUWm7p+vtxZVcdwAVhXhrfR1MZ/godRPtgc1KZmHinZmDQhhMFiQodyrEX MGRB04NTWl46qPNW2Qk3fQ07RfMNjVQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1709259385; h=from:from:reply-to: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=5cuFXdCHzzWXu0oiW3kPcFQ29IXMbiDarSwwKonCBIQ=; b=7q6cIrTXGiXvpjazhjBjAqeZS6vB5FuKVy1OmPnyDHyTeWPPbAQIlwlB8ZZIOpjXRJFBQZ 9nP3JKktKbGnZqDQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 24DEA13AB0; Fri, 1 Mar 2024 02:16:21 +0000 (UTC) Received: from dovecot-director2.suse.de ([10.150.64.162]) by imap1.dmz-prg2.suse.org with ESMTPSA id 34USLnU64WXiQgAAD6G6ig (envelope-from ); Fri, 01 Mar 2024 02:16:21 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Matthew Wilcox" Cc: "Amir Goldstein" , 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 In-reply-to: References: , , Date: Fri, 01 Mar 2024 13:16:18 +1100 Message-id: <170925937840.24797.2167230750547152404@noble.neil.brown.name> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 7B3B140012 X-Stat-Signature: a4xxwwrbuoiq44g6cm6hcwft134s4p8y X-Rspam-User: X-HE-Tag: 1709259387-197387 X-HE-Meta: U2FsdGVkX1/ExqPI4Ihkn4n6Ev9WB9WFThxCot4T9ZXgykNWlXvchKpLfl3U16xKKSdG2cUFyOHKI0yConBC+r6axYNP6A1kdAj/icoNiv6KJPchhtOjKyTFzrFEBg9JxvHP6avx/W1DEMG+D4vpcK0rju9cS10azvkW9iiO2Ykvy0DNd0QUjuwzQbfkxGjzSBySMp0LRdA1Oj+o8Br12GmhXI9VajTQSelHm514Zh562Rl/HU3OgDKIcFdM/nqH1dW87XBTYvJisbjOupDlxlBb34XyrIAEUipxWi4HFd7Bo1L85s30Cb6iUIwqacnzcHgbjpDO0wwQDwXluXGI3K1YeP99UyuojmC1kqqdZrGzmcbG4VfMXCRzQbn7i71r/2VzxZuqt9B47OEuVBZgxwvJ4kZmng8C0VrA7Uvo0zpjn6tJknaiob3O74qeuV4Oqp8gra+hrEfghXxGx1GLq0PKlhSSIzRM8JkSbbdGFRRRLlZVlrwLhJe90NvGM4sSFK3pMkxFiFVWksD3gKG+3r5sqDDoE2UHOJPoChL6522qqtOwIhABDqSvWhtcMTUWQ6NMrGe9pxvumHUwGmpjhkTaORRgpCHEtUnyB5out/Cf+k7ZHliKJw+fPQDiFYSFQlV+rkiHmZS06Rn+cujjWh8QL8zofVZpxq6ZXwHPyE6SKPuIAh1S4DglpaDtuPlbATv3z6P5D+4z9TMEAclj7p8juR3sIQmDMY+dmwDqpVkwVtCNcbjPsmpfQLSfNSfAbuPma90sYP7uE/kkeptTmR8o1lKWaGDKb+xhhktF0C10nBBv5Ut/cKWcJawHXfhcFoZbZpgOaUAQ/bKmjAbzoe7XbZdqe/UXlkV/9KN25Ba3+qGSK+DdT9g52bvHdf1xuH/9HkFx6ESCFpUAYiKTOifJREOCdL5zxPIuMoxpE5xC0FwbS7nT0p+s6Fvy7GJs36+94hKLXDgmQja2KHC 2oSbF6C4 hdGK6m75M+k2G6E6gyL5EvZtbWeWpYxEDAGJNP6L5GvDtOeZIiPR/+E3UbkuudHv8ukzo/1CenWl2GNzIU5n7uq79vongbkENB8kU1vmELDb7NjOMryxeIOh+LsdWMw87oUxYU2TNtGqy5wM9DqjtNOL4o1qlY+XrTDwV2ZtHSfZOmVXq9ZHg8BPWKJtPfA2feng8YJGkdsj6gjQNMkRreqe4VNMn00UQkDWILBaERwjDKeMfDBgAJqUPBAHNJ2InTK25nd/fZP3qiJlumVD316WTjq7+xz526vTX 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 Thu, 29 Feb 2024, Matthew Wilcox wrote: > On Tue, Feb 27, 2024 at 09:19:47PM +0200, Amir Goldstein wrote: > > On Tue, Feb 27, 2024 at 8:56=E2=80=AFPM 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 w= ith > > > some ways that RCU's reactions and responses could be enhanced if neede= d. > > > > >=20 > > Adding fsdevel as this should probably be a cross track session. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 While we are considering revising mm rules, I would really like to revised the rule that GFP_KERNEL allocations are allowed to fail. I'm not at all sure that they ever do (except for large allocations - so maybe we could leave that exception in - or warn if large allocations are tried without a MAY_FAIL flag). Given that GFP_KERNEL can wait, and that the mm can kill off processes and clear cache to free memory, there should be no case where failure is needed or when simply waiting will eventually result in success. And if there is, the machine is a gonner anyway. Once upon a time user-space pages could not be ripped out of a process by the oom killer until the process actually exited, and that meant that GFP_KERNEL allocations of a process being oom killed should not block indefinitely in the allocator. I *think* that isn't the case any more. Insisting that GFP_KERNEL allocations never returned NULL would allow us to remove a lot of untested error handling code.... NeilBrown