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 ACBB2C54798 for ; Thu, 29 Feb 2024 04:44:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29F3E6B007D; Wed, 28 Feb 2024 23:44:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 24F7A6B0095; Wed, 28 Feb 2024 23:44:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 116A46B0098; Wed, 28 Feb 2024 23:44:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F2DA56B007D for ; Wed, 28 Feb 2024 23:44:15 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4EA3FA0222 for ; Thu, 29 Feb 2024 04:44:14 +0000 (UTC) X-FDA: 81843599628.17.647B45D Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) by imf29.hostedemail.com (Postfix) with ESMTP id 63BD6120008 for ; Thu, 29 Feb 2024 04:44:10 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=O8h4leuX; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf29.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709181850; 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=5hpfWgC5IYjIxXvFKtiaQ0NzJ+pS3LY6ypvLK/34uy0=; b=bKry+FhL8LQE2N5TACeoGS4yM0K3Q4yFKOV4xrjE7lIE6nyaams67DR2Gl20VWCRFBlpy+ qi7Lw8C4MdWFyOp2JU+suWGNTyKrFzUpCBUU3GKRJnJAaDDTnLGUL28PYj22vJ/NG1cL1U Ju7W4vYO4hSjUabovfY7Wk9oC6xJmWQ= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=O8h4leuX; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf29.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709181850; a=rsa-sha256; cv=none; b=xSeJMvFbyVM97/QHZIgEGl49I6nEdjACQ1ftwKwwguARQR65TpJmMOfDRP7rTHs4bJzpU/ vw6TK0aYjI8DngJJhWX0e7HPCN6Y9v5VrnYpJ6+GeV8hDTMxzgkdf5PGDhLbCco9N7CtP4 vT+jXXzyq9BJTSQG5LEO0u6A+tzjF0s= Date: Wed, 28 Feb 2024 23:44:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709181848; 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: in-reply-to:in-reply-to:references:references; bh=5hpfWgC5IYjIxXvFKtiaQ0NzJ+pS3LY6ypvLK/34uy0=; b=O8h4leuXrMp2skvrLwTkhIn/YdbeKVHiJxWWOtkilZ3MyW4SP2+PIddtMq25DNQZWfprOa rQKE/PLjOevz761Tq3Tk206du11zIhqifpZf7KOc+1SceMoOOcy02wulvvURx2x1OSZSz+ 5JqEcYFBCVSQ2J7mSw2NXiQ7KKVQh2I= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Matthew Wilcox Cc: Amir Goldstein , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel , 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=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 63BD6120008 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: p8ganninbiwd34qqms9ezcne7h3ti9zc X-HE-Tag: 1709181850-506546 X-HE-Meta: U2FsdGVkX1+SnaXlBC3YLT4TZ6n74NKq+psyqGI4YHTwFCdzO5Cj96TGDqisMKKAgyzQoYiSirDnSHcaP8OOzRQd2y9veIbWfdPfsALs7KdCMi36h/ehOhOPlFZXVd64YoAZWGuNaF+x4nXhLd505gZqffKf/TmFz9Mb7tsFr5zlCfkIgsxG1Vi86q4GEqYRhrv873lCXX0T4AaALjqSw+1e3NH0X/ALv4cW92PomDC61IeOiBU+K1Uyq5PZomB1HehMZgfusd4rPxlJgvII+aXEP9ZMzSM4YU2LEpImtGfpbWGNRG/NqANeu69QkeagkHyZtrtsbnF7Da3j867V2MAF3c0DefVzp4+EMPSZNgd9XcQt0M+BV69hNi6p23YXzH/AMeqn3+qumP/jAf5qh/0JzyOXKtwfQatvhAgc/FCY05TrOL9+uwJBmad8cLVOwmSKpfisQ+K3oRVRLsw4DcJSDpvTA8kyportfV4GuSoOykblHM680FNV1Q2JGQLjNyuQTqCYXYTOOHvullh5IfiBkSNLiySQawo8WmqtL22Gqf/0ZZFpFpi8Pfir00jy7+DRlpb8ySGTPcWxI7B2Ht+UGbJjdkECPTm/84ZxkPVM5TkjPLj0rEdLPzb2Zk2ls37Ok0Zn/iLjjR1zoO5k+wpSLtSHhxQZ3i0ofEikhlV1E4Xb+Zx1yvKyp+MIAaQB3Sybgid5stuhMduvdK8xjUtK3hjYJrZvX2YLp1uDUmWPrJL430KP8vdKwNoMV3KNykFhXYzVDjz65SXLPdV2IrUFFrQVpIfdO+Bsow2DWb2j/WHuA5fA0zuDd5yomD/KOXQ4scjfkO35lDxdeq2a1jZLpLwLIkzBMaz5/8Z+5FWFJjm7lY5J6t+gv7nhiIp8ubR+K88quFFYOaP+nobwVxboQ2e2pHY7GixywjTc63wDCA4MEfXUFfdvxKa7f6vxXjiPPqg7jZOc9aM2NJK Wk0cT8ve ZjOXoP1Gx7n4mERSZJDjsqZRr9w4o0xDvwxNy3q2NPOVsDyAFyY23RqM5E/JUFN/M40JIOnbWS4jujkY= 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, Feb 29, 2024 at 04:24:52AM +0000, Matthew Wilcox wrote: > On Wed, Feb 28, 2024 at 11:17:33PM -0500, Kent Overstreet wrote: > > On Wed, Feb 28, 2024 at 07:37:58PM +0000, Matthew Wilcox wrote: > > > 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. > > > > Why would you not simply mark the writeback path with > > memalloc_nofs_save()? > > It's not about preventing recursion, it's about guaranteeing forward > progres. If you can't allocate a bio, you can't clean memory. Err, what? We have to be able to allocate bios in order to do writeback, _period_. And not just bios, sometimes we have to bounce the entire IO. I keep noticing the mm people developing weird, crazy ideas about it being "unsafe" to allocate memory in various contexts. That's wrong; attempting to allocate memory is always a _safe_ operation, provided you tell the allocator what it's allowed to do. The allocation might fail, and that's ok. If code must succeed for the system to operate it must have fallbacks if allocations fail, but we don't limit ourselves to those fallbacks ("avoid allocating memory") because then performance would be shit. The PF_MEMALLOC suggestion is even weirder. mm people are high on something...