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 B5D6ECD342F for ; Tue, 3 Sep 2024 07:06:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C3B848D0141; Tue, 3 Sep 2024 03:06:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC4B98D0139; Tue, 3 Sep 2024 03:06:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3E088D0141; Tue, 3 Sep 2024 03:06:22 -0400 (EDT) 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 8277B8D0139 for ; Tue, 3 Sep 2024 03:06:22 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2C460120A3C for ; Tue, 3 Sep 2024 07:06:22 +0000 (UTC) X-FDA: 82522543404.26.ACEA627 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf25.hostedemail.com (Postfix) with ESMTP id 0BFBFA0013 for ; Tue, 3 Sep 2024 07:06:19 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=gzSXwIgx; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.41 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725347157; a=rsa-sha256; cv=none; b=772iZbsQ4xeS4ce0ZTLQdL4bP9AOu4JWYhlpCtH1Vry0TffnN4RruFjb5WdLFXA8r6kgMR IySzA6HQAodXctu+5fMPNRwCFro5tBb9uJU5GmKTEhsYGk0WjZSFCy6YB5qIFjVxBtCp8f djSxW+yR/JmkuVoKmwAR2tVm7W9wkm4= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=gzSXwIgx; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 209.85.167.41 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=1725347157; 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=kvtznVhKc/eAuzlMN0NV0mbNt8/nqOdK8ldVlk9CEsg=; b=qNLouh84Oi+zzh+1RK+WaUTaOIfmsT73kN9/baV6q/YrI9SwvIs3SmazWPEL7xqCwwi2pQ thas7w4nZKXwxVIp+smplPFjOgWtjuZR+Qx2e2PkXAiT5KPb6FbNfCPmSns0v+EcHAW1A2 49sS/o2vglsMO3CBB8OmyamKzW6pfDs= Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-533496017f8so6651690e87.0 for ; Tue, 03 Sep 2024 00:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1725347178; x=1725951978; 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=kvtznVhKc/eAuzlMN0NV0mbNt8/nqOdK8ldVlk9CEsg=; b=gzSXwIgx1AIXB+LZ5A6M79jMKCaKKJKB6BfsMLlqaPdFyJa06rSbpWmZy1XB3Gztln 5Y+8iFi+rGEQyava9LGxkP5HSoEkljEdyaADegS0P9zZ1HS9BflOQSYl7CJCZE2gnKSo LNdQlSdmecpZhXbzskgOyzdVCFbH4+LGy9r2Okqx4PmpsSH7Bg6CWYJgFdOqJ4XCJnRC C1SHCV3feorUt1XOvIgVG63Dy8LnU5+AjTsRHkuSTczOkwM07fUVPVD+ArlXDADKAcse RtZw3V1JvdD2nbmcgMnlyPWk8mdaNLYfuSRxrxw/mlsUx5eVmKaziyNVZymyJ+qByz6a O5GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725347178; x=1725951978; 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=kvtznVhKc/eAuzlMN0NV0mbNt8/nqOdK8ldVlk9CEsg=; b=HCuweuYHQ1GETV9Oeny3nlXqQXrO8ukrvV1zQLAlOF1v6EYXI/cr4d9jLSEHoDM+2Q ByKBVscdVmr0OMXQq+YqUdUzHcQ29gbD+d2OWTR4wqYtnjMqfcm9u/Ysoy38GqobjG5Z WwwTieAbFQfTSS61lYxlKkpr+o5YeGs9ZPo1BjPeMpKGgDS4/DPcIjwrG+Bm4KtXUG/P KNrUE33tHUkOWkMg0wZmQO6Lc9s4+w8SGyn8iM0qzBsCOEAZvTFqTc7WzKEXSZjYkssI V8nJZC251Ihk0p0hf5uZDP85dwAir58lpPaXSJlLMwBOq08LLEJLjWIcjAC98c7r0Mvj EawQ== X-Forwarded-Encrypted: i=1; AJvYcCWcu9YSZkhtv54PBvYQjIb08QjYg20ZKpR5Hjb8jQxmMLpSduNxaA4p7jJd/fmjW88FxZGQ6VFcqA==@kvack.org X-Gm-Message-State: AOJu0YyVoCZbDjRVmoPygG8U2XcG0R324B6AHJKusyFcM1hHgsBE4tpF c9yY0TboA5FlYQ4XozFqrfggIKbjMjI9LV0u/ksLeP10Zq8T65zG0vBZHYy53Js= X-Google-Smtp-Source: AGHT+IFgb9y6scjaaJ6Ac8zMHkpqw9NAXdPaozwZh5IGu1XzjDYc4UFvGDiYVT0LhEjt+nA8PFhBpA== X-Received: by 2002:a05:6512:159a:b0:52c:e047:5c38 with SMTP id 2adb3069b0e04-53546b0401cmr8748808e87.15.1725347178053; Tue, 03 Sep 2024 00:06:18 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a898900f0acsm646160266b.73.2024.09.03.00.06.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Sep 2024 00:06:17 -0700 (PDT) Date: Tue, 3 Sep 2024 09:06:17 +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-Rspam-User: X-Rspamd-Queue-Id: 0BFBFA0013 X-Rspamd-Server: rspam01 X-Stat-Signature: sg1d7f98cg8xbas17jbyypwo1nhj4sy8 X-HE-Tag: 1725347179-17577 X-HE-Meta: U2FsdGVkX1/oa6ULzIjUansYYf3wPQ/EduxS09AB4j0aDDsLeihEa/hOuQs1ANkT8L+gm1UoZj1rVhGZ+4EssqwSYpY5stXfRyLYmkPeh5VJ5JKtTkOxOI1ghplhsf6ODgXqtRFU5FoIdCEgttiDRze5xfQ4wpLmlzZbe7QWRceBLflsx39Bh2su9Kf8+BOlc/JXPwg6A3xdqZgqQgaHz1lBls64/dc7hcFhhIYaWivVJ4ey71lgbEd4SzMOZFxQJPmNeqSLggivjTt2DG7dHVE0+Uka6cosOfUahVTtwmqTk04TnlQQh37oX6hYQpOhtpspuEawrVn2rzigP6yzqET3Os0g/WsQAxsBy0kg4q0FHCMjKnvm+syMg9PxT/cqmsyL55DS2baZ4ONoXB8Unn9puc0t/vtZMsr3bax+Rv1VrncHWapQH1yJpkcaLO77lmlT+/fkpZAr+AdfNCgx7SlQJ0C+M8tZvgmF0lamu4lbmXF4168ZPSkZ7699R7/W7VljmsBICTt0ZYi0Z8BxFPP3zsV2Hchu7nks+yHQ7ZWLMt27nWHaDfzhTmVPWn4Ve7jJUimZ7HTSrIbg/Ok5OFStrCVTCrdtRVAC3voFu6VyLLRp565S30YAe8jN76mt2n05ULkHClxTV4hOV081GGnjCwwR70hOeXv9hqFDeUokSwaeUWxnFgIafI1/2FHIeQDWpaiWfacINvkW3lCgy0niu3ymXZFASdaowtJinBcyWKOm2PzKuYeOHVJDYzCg0+T7ZSCifelZf053VQJEssA7vxv7AH6/Xc82jNZBmeq6YKMbO2EKW2cyBBAc3N60f3IdlpisqMM30hp8+DraYD+kuFEqTM2cSmnJLkw0KKKN/J9AFfZ432cuFH9R7/GVT3D5kd1I8LwW7aonQAtw9jqbSVrTqpoKw+3A2Jn9i2Qikk9ktGPkDsDiNlD40/Q6a1xVs3Lk9IEst2kY29Y Opyoznrg U1z2QE1bF9OrcPCc21u/yCZE7wB6A7EQAhOk+MBQAYeOVitQCyMQdSoNrZukUr0HPqS8qTTZbd3PNgO/TSo9IllqHaz3r4guB2RNmtYKYngdsz7WlfPMSHuXn1QCnhDlaCJQ1wJdqbsOR7VZUS/hFRBu0/ZxkvFEc/ZdWpyDU1c8nI2mzTAa8q/JWn822SwPSpt7IJ5hN27Jl3iqWR4ZmhYLAXQ+BMJ/fkAyDUurmfcqS9sElyRlvbmcUCBa48aELI+x9jUkBJKm85QGUtoaHOig0cgqZ8xPTwJokgggguwXnJL6Qy49Ku/soYvN36K0g6FF6BSDSUiPM7PdcdS1qtLIHsE5eRka2mMGmMVgTS0uonI5IXfhu8KaIHNQy727zspOVZECyU24d1qh1a3uLrEKRO/fM1h0P5hzwx8TFWAprbdscOlXYMiGrLw== 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 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? > 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. This requires discussions not pushing a very particular solution through. -- Michal Hocko SUSE Labs