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 B603DC47258 for ; Thu, 25 Jan 2024 16:11:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A7156B0095; Thu, 25 Jan 2024 11:11:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 357606B0098; Thu, 25 Jan 2024 11:11:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21F786B0099; Thu, 25 Jan 2024 11:11:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 103CA6B0095 for ; Thu, 25 Jan 2024 11:11:41 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D63481C182F for ; Thu, 25 Jan 2024 16:11:40 +0000 (UTC) X-FDA: 81718323960.14.E1FFF21 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id 523644001E for ; Thu, 25 Jan 2024 16:11:39 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=THjYKDS9; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706199099; 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=kYtGfh7brmeXFx2nN/OWMcBywY6OoQSQw0s7tMqTk5s=; b=Ravlpa25oOq04VmgwYS6+o3waJNdNIFtsTqP0z+CwOw6BusMdlX8ihz8q+4/FZGrEJJGZh QR4dIpYfd2ke4gL9Yj5at4J56DdYURlldkullSsYjjylKfHWjiFvbSOmxCyj5gn7lZG5Lb aPlyngrK4VBLELjlb+XFm/m+r+cU2qc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=THjYKDS9; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706199099; a=rsa-sha256; cv=none; b=PIJmTqCRzCEx2lnq0FSsSSjtzvU4g8r6vfG6syMMZroV1HvZrKedWVdc/GZy1A3o7RxoFc ZCOlS8reCQEmxYc9Mv2lu8GRQaACVeSLj9AUzyfQnRR+7kKfF85ohfVU/cxwDsYeOurJzE kC2TO4Xbgc1eNc7Rm6ShHckzrQmgySw= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=kYtGfh7brmeXFx2nN/OWMcBywY6OoQSQw0s7tMqTk5s=; b=THjYKDS9V795JWmm7rTHeSVhHX QS2PO3MCt5dzAmV/++OnZ7MyMjDgK3S9sDuj63aK+ypZqQJ30li1oNMICJq2Y14bhNmBbjIjOEkRS eXcd5zp+FZyokuBChNeQYc12qvcSNobReQyAnEv5VaDNvOTk4bL0DazzEHsRlabzZ3VAj62mtbmE9 zxcSZ3GZ1ORBR+jmTgMFYyvipo6jpndl7llpXYjmwuD2RbJOJky27O2Gzbwk+i8mdu8NxNoWDgQ3A Sp9cWp+pb3sWBPw0/fxAI+9fDiP5QURc0GMs9GG4GT8te4YMuopDPZI987MzQJ0SGKocYkjL4cJK8 8eNulXaQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rT2KG-0000000AS8B-0H2I; Thu, 25 Jan 2024 16:11:36 +0000 Date: Thu, 25 Jan 2024 16:11:35 +0000 From: Matthew Wilcox To: Jens Axboe Cc: Christoph Hellwig , linux-block@vger.kernel.org, tj@kernel.org, jiangshanlai@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH, RFC] block: set noio context in submit_bio_noacct_nocheck Message-ID: References: <20240124093941.2259199-1-hch@lst.de> <20240125081050.GA21006@lst.de> <07de550c-2048-4b2f-8127-e20de352ffde@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07de550c-2048-4b2f-8127-e20de352ffde@kernel.dk> X-Rspamd-Queue-Id: 523644001E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: w44s8kqhy8xhj7zb9o4bk8kfdfc4fjnf X-HE-Tag: 1706199099-420589 X-HE-Meta: U2FsdGVkX1+/ZWDIm24LO4KP8+u/ohvxf8wYgW61r+k28h1io/zxZBqrxYlMuYPTKmK9OuhNX6nUiTnlRXe5t8NXpTn22sWN4EB5/FThd+g8DVPqSaeNzqAzMlBZWidwLv5vm4IqICbSV6KUukLeJ8YfIaBcqjs5kmtVCuZrCq34qNK9TbdJEZDkx8gLbZ4gWicuGziNi3tsZN8ZqIBuJVhoMZapeSwDwLUw0jBW4rVjlH5nbwV6dQfVKKWSGLSeNpVRY3FogxTnWNaI9na5fFWt07KYYSPJ3N8qje2Z24GNLxZ3SjPqWNxAZun+ZTOJU4O0c/A8TqBOh1srgUUMGbWW7WX7RamlyVhb9/roGC+l08ljmllXXPjJJ5mt1uA6FWy/plNg+jGaGSyttNB/hEqHteuD87kBgUkCVXciHYA06qcvaJhxoZqZY7GMoRCQ6J0oT31XUqgjS36GESDRQEn3+qcYQ98gHIfsyX0wJvn13ERzTBYKO5YEUMvS/H/npG1gOuAh8VFzEa4FGMeLrqQT37Wup/Y4dK7bWfO6m1tHbay9rccPlxI34D/Jwd2Rv41G/SWLOvkmNOK9E5VaCBpm96zLsT4GaJIf0okgIhccOXVzVP+CIDF/KsS2eSJ8/mFMJCBmSbBcsenSOYHy/6ald+u31kQq5zLAEfvXAlWoB4q1B8B4ewsCBLr5Vfn6gG+86o3Z65YdVkbrh5mUnvujjnqE4u96WOjiVAqqv8y1mO0kkD/Q43zVmAVG4ThDQa4BG9YP+zjOcPVgh9p12G2/JpQql+Gy825CWX6Bt7erX5YnitWfHVSMcFOzcG13pHCdmkP+zCHZ10A1bhbnzvpy4r9LdUteW1d/gDWARwZzqOBRnRBdY8tGjV+1uKGx 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, Jan 25, 2024 at 09:09:44AM -0700, Jens Axboe wrote: > On 1/25/24 1:10 AM, Christoph Hellwig wrote: > > On Wed, Jan 24, 2024 at 08:40:28AM -0700, Jens Axboe wrote: > >> On 1/24/24 2:39 AM, Christoph Hellwig wrote: > >>> Make sure all in-line block layer submission runs in noio reclaim > >>> context. This is a big step towards allowing GFP_NOIO, the other > >>> one would be to have noio (and nofs for that matter) workqueues for > >>> kblockd and driver internal workqueues. > >> > >> I really don't like adding this for no good reason. Who's doing non NOIO > >> allocations down from this path? > > > > If there is a non-NOIO allocation right now that would be a bug, > > although I would not be surprised if we had a few of them. > > > > The reason to add this is a different one: The MM folks want to > > get rid of GFP_NOIO and GFP_NOFS and replace them by these context. > > > > And doing this in the submission path and kblockd will cover almost > > all of the noio context, with the rest probably covered by other > > workqueues. And this feels a lot less error prone than requiring > > every driver to annotate the context in their submission routines. > > I think it'd be much better to add a DEBUG protected aid that checks for > violating allocations. Nothing that isn't buggy should trigger this, > right now, and then we could catch problems if there are any. If we do > the save/restore there and call it good, then we're going to be stuck > with that forever. Regardless of whether it's actually needed or not. Nono, you don't understand. The plan is to remove GFP_NOIO entirely. Allocations should be done with GFP_KERNEL while under a memalloc_noio_save().