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 D8BD2CD4857 for ; Wed, 4 Sep 2024 16:15:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 529CC6B0334; Wed, 4 Sep 2024 12:15:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 488EB6B0336; Wed, 4 Sep 2024 12:15:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B5BA6B0335; Wed, 4 Sep 2024 12:15:27 -0400 (EDT) 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 068F36B0162 for ; Wed, 4 Sep 2024 12:15:27 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 66017AB00C for ; Wed, 4 Sep 2024 16:15:26 +0000 (UTC) X-FDA: 82527555852.08.1E2A5D0 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) by imf05.hostedemail.com (Postfix) with ESMTP id 3A65910000A for ; Wed, 4 Sep 2024 16:15:23 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=OSWlWl0y; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf05.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.189 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725466453; a=rsa-sha256; cv=none; b=ll8f5MxO/CVQkhmv8N8KrNtDidR1p5vmd4d/33C0DoIbVN4QFng38vC6dV+9QokeLXTckd DqA3IWH1pBadn0ERorEEj6xYlAgKI+Ko4Uno0erGhjVIxNYXS+G6IUoZxzw1sj7/4yVhB9 xH3fw/KIjFbTevb58NokF9RkuJobFg8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=OSWlWl0y; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf05.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.189 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=1725466453; 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=gFEcuTW9GDd5R6/s9Ksgowfe9BJ1JWP/ZMXulaxqbcg=; b=bFqNLwgjY1eyCelEFNIaV1B81eKnH2uNubVbVY6jIkLhQ3XKUQUX6KV/FMr1w4LFfFwfW0 8eHR6lt4T4KxFk77yQLFpXWsfx18uJPTw0f0JuY+d8o3Sw4JQLu9gFSF+rOdHd7EquhlF5 KVfHbEtimicWm7MeT3c4xdfKxnZ66Qw= Date: Wed, 4 Sep 2024 12:15:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1725466521; 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=gFEcuTW9GDd5R6/s9Ksgowfe9BJ1JWP/ZMXulaxqbcg=; b=OSWlWl0yQRlbiZ0Q2PnP/1MUfPHPqQY2Vtmznt8DU97IsUs2JjjIyV45FCjfImOpyIQECz F+8Qul2/k8BAWHy8aJ1wqdv5cDJOXlXprRVoO4U7WY+VlIRCxyuwZJmUVVN+bH99o0dT9s 0z1NTY1JvtiD6Q/WC4XdwboIullwJAc= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Michal Hocko 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-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 3A65910000A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: gbpqbzgcsx337nc961dfcgjz5ty6r3r4 X-HE-Tag: 1725466523-160687 X-HE-Meta: U2FsdGVkX19KHGonq9x+h5wqZoogUqs8j4g4Z4ypMutqQZm//NY25vx6/egiT9eMIzAOdM2jUwprqeutCOZDKmpd05I5v7Iny7u71vmi3zLJqjUmfgQ8X2Vd1EjMy2LSG820/DFwBTuZ1+ZBv/ln50mtmjCMaEo4795Jhd7h3OJrTTRFA3yrcgsrRKc0jDO/NiJ/FalXTO1xAIg7Xsh9Xn0pZro4m5fW4O6h1lB9gjYwEQxjSM0PhMrAWMSjqqs5HPG1VCQfmZxDhELtuQ49yGWFqbLivlK52u0RRPh5gCcMGeWY1Hr7nK8L1bfNOtGiF/NflqfnXgGhlfUw1vgZIzcwDLEtz+3cV1w5eCMr1hZJiJN5cktiYWb3+DYV775Aq70FgGNNmszUHAFwGaZU4EuzFS8dtFB7Md0WYiqWdDc1gJze+zWkHsia94iXe8LNoUAKPHuJ4y+0Gnulyqfp8jcgY+epVmc0aQjNcLBvS37xj5wxD1o7XfONXo/YQDsQaL70e+kmdVCpaw+0SLQI1m6PcpIyY6T38POciCOEWgFkbSoR0y9g8cm6Ue+8O8XYj7pn/uTed2hwLZMW11qDgMOo/Qj3KI9FhLAdiyxmLg+eYkgb+kndbTJwAcnJa2Ci2Ew4YGPhjmJhSbgYEvyMbTuYDYVFKdL0JvpNzAnVR/UQimLAUQm4PbWfLNgpPwlPOx2AF7xAXS4rxnit+EGGFaVSPAMlWtDchcuN7+sOPEsT80Tt47jDgDRX07yPSFR3GofxEiJYYps7HP97y2731C/LRhD4Rrvi43X1Ys6ReUSI4kASZZ+3jsuCdrof4o+JeCzBElBH694IcAJKD7Q0YwijepVhyU5/XAuBvw1Oyag/1kGsRHcxaXamPxUSBH6klmvQl1+erJcPvQn+C+zlMUecEyK33ovPAOGkWFqRxcWg1uG4tAH68xZaxhGaR4FmZ9feEENdZsyrZpVnFTc 80H3DFWl uKI3tqJGyc7cgIkwc5ySZcZBR3Xp12jPHlsbtNvuCxQhy8PxHMqs78zFXc1Le0ljw14SDMF6K1tmOTgrYECiI0PRed5vbJQmP6ut9T7givkLRMB4IhP/z9GxsIMrqkdAu9KVCfV06AnznYAnvYNFCU2BhFcACUko98yzzr8h8CzMxQgJ4O9sdT6JZJOn66AzbohlR9ZNAbebVhldN4h4Acl79skcOhEvfc4WpinAywn9ByezWUzSJ30rBS0Kxux03x3Q5Ls9BWovgkjNWNnkmTuUVFmgH3d25RwWPn2xgoVgRuMzUNOpHTbmNlI4UG3Ylsz9AprS4PG1RU+c= 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, Sep 03, 2024 at 09:06:17AM GMT, Michal Hocko wrote: > On Mon 02-09-24 18:32:33, Kent Overstreet wrote: > > On Mon, Sep 02, 2024 at 02:52:52PM GMT, Andrew Morton wrote: > > > On Mon, 2 Sep 2024 05:53:59 -0400 Kent Overstreet wrote: > > > > > > > On Mon, Sep 02, 2024 at 11:51:48AM GMT, Michal Hocko wrote: > > > > > The previous version has been posted in [1]. Based on the review feedback > > > > > I have sent v2 of patches in the same threat but it seems that the > > > > > review has mostly settled on these patches. There is still an open > > > > > discussion on whether having a NORECLAIM allocator semantic (compare to > > > > > atomic) is worthwhile or how to deal with broken GFP_NOFAIL users but > > > > > those are not really relevant to this particular patchset as it 1) > > > > > doesn't aim to implement either of the two and 2) it aims at spreading > > > > > PF_MEMALLOC_NORECLAIM use while it doesn't have a properly defined > > > > > semantic now that it is not widely used and much harder to fix. > > > > > > > > > > I have collected Reviewed-bys and reposting here. These patches are > > > > > touching bcachefs, VFS and core MM so I am not sure which tree to merge > > > > > this through but I guess going through Andrew makes the most sense. > > > > > > > > > > Changes since v1; > > > > > - compile fixes > > > > > - rather than dropping PF_MEMALLOC_NORECLAIM alone reverted eab0af905bfc > > > > > ("mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN") suggested > > > > > by Matthew. > > > > > > > > To reiterate: > > > > > > > > > > It would be helpful to summarize your concerns. > > > > > > What runtime impact do you expect this change will have upon bcachefs? > > > > 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/ > > 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.