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 779B8CD4857 for ; Wed, 4 Sep 2024 16:51:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C8B3D6B011E; Wed, 4 Sep 2024 12:51:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BEF1B6B012B; Wed, 4 Sep 2024 12:51:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A655F6B0122; Wed, 4 Sep 2024 12:51:03 -0400 (EDT) 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 84A9C6B0118 for ; Wed, 4 Sep 2024 12:51:03 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 18703A151C for ; Wed, 4 Sep 2024 16:51:03 +0000 (UTC) X-FDA: 82527645606.15.C6B89B0 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf02.hostedemail.com (Postfix) with ESMTP id 2CBE580005 for ; Wed, 4 Sep 2024 16:51:00 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=GNPPhWB+; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725468590; a=rsa-sha256; cv=none; b=zpB4OoQKwb/iMAvNi2OMokk6tYCx4AsilygleahvQzBfxQfDGNkSsORvaQaFuOe9MPs8G6 gg4Hw3xRD3lvMCLCU1fkQyo5XUGIwfp1jF8O8tZQ76nTf2JEXXY4UEPvllz8iS0dYwUhR2 Otsc1vtGUf6HAKfXGSQyOLx+tWDO/uw= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=GNPPhWB+; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725468590; 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=n7rWeV+NWCdRf81fBZfPtxM1G+LxfG7gp5nBcYV4V5A=; b=oSIS1XXE5MqwVlkwJ78DeSNQg+ET02n0lnO25TUot2XV2kxpUuZfQJ1GmO10kUdMmiW/ei jJcC1EqSeVqX3Zrzi5Pk0b92hf66f7poGGYQbcA8W44qz/QGwtMzdfyknzD0VEfY8c+To7 kQjQtRFc6MVGpiOQHJzX6Z60rYC7w+A= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5bf009cf4c0so7152982a12.1 for ; Wed, 04 Sep 2024 09:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725468660; x=1726073460; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=n7rWeV+NWCdRf81fBZfPtxM1G+LxfG7gp5nBcYV4V5A=; b=GNPPhWB+cAx5fK2kRRvgOfbJc5VJbcmZK1xDbWH3lTpZlV6jk77Y5LFf4/vMqV1LW4 snGT+f1zII29nfHSN3iR6QU4Xzfs65B8VYpgw0t7N5FYO5hKn/KpsUxBMD7YF+9Rip7t fJWgIPk6NXymK41/1cspW9apjmFN0JmoBHkdg2+9w0ObMeB8ED2SoV2KCJlYUBc722Rm EybRdxx2hVqblXxMw6FXgQ8LNUySeWswgnByyTo3hyRouvHG0mEOHeGX50YQpayCReBB WyCA+tDlCUeS/3QmkmXHGWRwMz24tjXd+LcK/htyTN25w01BUuhp5MCZOG0zVBnHw+nH xiaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725468660; x=1726073460; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=n7rWeV+NWCdRf81fBZfPtxM1G+LxfG7gp5nBcYV4V5A=; b=qilIRaFnhb13W8OUWlGQzM7fAgZLnoggtewSF9PQWNK/raJ92qZtJnIFa2uaf76Pau FLc0Xq0vBWKtqEbWrax11Y7eUdmWRaAlcZmc5+VTkVBEOZdfY2R7kOjdM0aam55pjfsT YRwBvZ33ODLFenhuYNffFE7Ok/SELiFzUS1AXNUK5diCWJGCnVMEWPF74PmdmlMroLzy xTQwVHsxxp7+wGiRW7fm1ODmWL7nwQcdi1PqtNpy6LdZkvAARtewe6EdNoNl2iagE9yA a8uCkSVE2kkmI6dZSQaUjd1qrbCnyPZwLzv1q+8f7+wlfOGRDSejiB2LvD6hrXHx+VkB o1kw== X-Forwarded-Encrypted: i=1; AJvYcCUR8VqqrRIQlBoDtOlF1Lia4J43OQukQqEzRXJFdxLnJm1Koi9HQbopkx8fVeWJ3wYkG2dcHwtjbw==@kvack.org X-Gm-Message-State: AOJu0Yy2yf54svigkAtPYPu2hbH5/ZJiY4rBCvx84XgI1NJcwrrOjEt8 h4ufKluez7tKBYDyEADnaE5WUkTta7D5hZ8VqPGDbbUk+x0/n9Et0ZU+aj5Fk38= X-Google-Smtp-Source: AGHT+IFALtAoVHEjAWS0GLsxnXTvv0LRQZ1z3Mh6tmtAzZy/u4Bi8AQyayThPfA0wkbnRHgLuqmbGA== X-Received: by 2002:a17:907:2da1:b0:a72:69e8:f039 with SMTP id a640c23a62f3a-a8a32df36f9mr369433266b.12.1725468659495; Wed, 04 Sep 2024 09:50:59 -0700 (PDT) Received: from localhost (109-81-94-33.rct.o2.cz. [109.81.94.33]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8a6236d089sm13263566b.123.2024.09.04.09.50.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Sep 2024 09:50:59 -0700 (PDT) Date: Wed, 4 Sep 2024 18:50:58 +0200 From: Michal Hocko To: Kent Overstreet Cc: Andrew Morton , Christoph Hellwig , Yafang Shao , jack@suse.cz, Vlastimil Babka , Dave Chinner , Christian Brauner , Alexander Viro , Paul Moore , James Morris , "Serge E. Hallyn" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-bcachefs@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM Message-ID: References: <20240902095203.1559361-1-mhocko@kernel.org> <20240902145252.1d2590dbed417d223b896a00@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 2CBE580005 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 71fjf87otp4h46thtnh3nqfjz796xabc X-HE-Tag: 1725468660-985909 X-HE-Meta: U2FsdGVkX1/4wUwZz+yZ6mlmlfaTTiWbhJXUDpmZie/4FNkPw4q9jGnYYCAlMLEqYhfccFW/V1n1NW+bLq/w7crwPLKHpVa2CDAbMMwp/XbMUX9WgWoopK/fsGVeaeZMJ57KtJj8YPk8Me69ssZova5FxpAPMPVjYivNbUHm7xMYsLSf8ldEDahjpLkkq0lWz/NHXXlbpnfwgQCXWkXQKJooI/cLIVoapQihbPgr92gDvFxYXP2PHC49cWQlCprrph8oV6tmgVlb+VvywfPqdRuI4Ho/jrwUw0rFGujPqpbqr6Sa99h+7jZs2UcvIz9sitR1bLqtcbXlC9L+dyj2rSgZDK45bR2pLuUUZydQO1INOAZJN+0q7K7O+3VaF7ROSE6CkNl4Kai56L4Uuqrlrd49kVZoXF5odNVJMAEpLs68irkQu5fJq5PEZTT1xvBsubVn8rhMlQMmeGxIJig5/VOW786Wl3EqYRBDM8PFqOEXuoxW16SLlV0sPxU56g2EsDQ9HS5rA0vpozf6Rmf84VHGmbxW8vem2HDKFbS0Fv5l3Ciso1boHP+PFCr7Pqr+QkOM2KJ0glhpjOehUFOQLHn0WE9pvvkf5GY4DvqTX+kYN/bbkBgezDOyLflx2EAidqpXR04Apm+sCVVVBuBzptn3guatu//5KovGLWAxmqIsKlXH32QMrIpApNgPRVLNjnmcEDkTqoSVU/jh1+JqgWK2789yrZTP1pHtD4/HxXlTaQ6ugwDobgAB6jLvfnH/KU+Se7ntvJKDBWxf0vOSN9/ihYnEj0nl5HC/g23V/IWJf33m7pUROrwLRWNGGa31aB7mdVybIszFXdo4v0rG4oCxxglZkNCj9Ph+lVl2BDX+V2xk3aVom2lwhp3K59A9qCjgNxGRkmQqlERotpYWrk3R2MLwiXgs8N03HQj3kO7p9aN4RgwepETIo6dyvMY145SpgpL0DHuQSi6EFLZ /V8Sj+zs hYaP2KjxFy5/eNrLO9m/0y2vQOpwW9JSnqnQZHNjU6rotbWAe30OhTi3fHWyEfIDmm/58eyPuQrqzuI8k2Eli9Du2bvYNTCOlSXhoXk6i9vyh2D4dRXC2us50vPdnVblTC6DU3le+iWOAI8MyjGVL9pvHhv4aVVBicki2wSD7Hi3jRzkUSdoO1dhEXXP4El1PHpKtZrlsJP0ldETBYE9KR1lzX5XCjsllcv6oZsoLhdDSbiNUYI4Q9qpWG5um6zB7UZxhtD6/D1QkMqqlDw8OHkOVTT86jXf5eAiNKmBA4p3r4Jkp735PQcYlJz42bxt/sdC7kyOyeZbxMTQjelpzUcuTiDATy6rilTmKY2Fnn1q0svMgowpftUh4R54apXhX5Kbs6K+sjvFPOZ8aTSBMTgD27Zrifhm2nWBk1HClg2Zwa481DioSi/R79V3U3KMNqy1GKICsEu3jNqtA9T2RUlQ+rOgWUItDfgKe6IcivnXIilRC4Co3TCqpvQu5HTTlIyU3 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 Wed 04-09-24 12:15:15, Kent Overstreet wrote: > On Tue, Sep 03, 2024 at 09:06:17AM GMT, Michal Hocko wrote: > > On Mon 02-09-24 18:32:33, Kent Overstreet wrote: [...] > > > For bcachefs: I try really hard to minimize tail latency and make > > > performance robust in extreme scenarios - thrashing. A large part of > > > that is that btree locks must be held for no longer than necessary. > > > > > > We definitely don't want to recurse into other parts of the kernel, > > > taking other locks (i.e. in memory reclaim) while holding btree locks; > > > that's a great way to stack up (and potentially multiply) latencies. > > > > OK, these two patches do not fail to do that. The only existing user is > > turned into GFP_NOWAIT so the final code works the same way. Right? > > https://lore.kernel.org/linux-mm/20240828140638.3204253-1-kent.overstreet@linux.dev/ https://lore.kernel.org/linux-mm/Zs9xC3OJPbkMy25C@casper.infradead.org/ > > > But gfp flags don't work with vmalloc allocations (and that's unlikely > > > to change), and we require vmalloc fallbacks for e.g. btree node > > > allocation. That's the big reason we want MEMALLOC_PF_NORECLAIM. > > > > Have you even tried to reach out to vmalloc maintainers and asked for > > GFP_NOWAIT support for vmalloc? Because I do not remember that. Sure > > kernel page tables are have hardcoded GFP_KERNEL context which slightly > > complicates that but that doesn't really mean the only potential > > solution is to use a per task flag to override that. Just from top of my > > head we can consider pre-allocating virtual address space for > > non-sleeping allocations. Maybe there are other options that only people > > deeply familiar with the vmalloc internals can see. > > That sounds really overly complicated. Let vmalloc people discuss viable ways to deal with that. You as vmalloc consumer want to get NOWAIT support. Ask them and see what kind of solution they can offer to you as a user. This is how we develop kernel in a collaborative way. We do not enforce solutions we work with domain experts to work out a maintainable solution. -- Michal Hocko SUSE Labs