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 6C508C54EBD for ; Thu, 12 Jan 2023 09:36:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5BEA8E0002; Thu, 12 Jan 2023 04:36:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C0BDD8E0001; Thu, 12 Jan 2023 04:36:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFAD48E0002; Thu, 12 Jan 2023 04:36:29 -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 A117B8E0001 for ; Thu, 12 Jan 2023 04:36:29 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 67113AC0C9 for ; Thu, 12 Jan 2023 09:36:29 +0000 (UTC) X-FDA: 80345641698.04.DB05A68 Received: from outbound-smtp43.blacknight.com (outbound-smtp43.blacknight.com [46.22.139.229]) by imf14.hostedemail.com (Postfix) with ESMTP id ABBB810000C for ; Thu, 12 Jan 2023 09:36:27 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.229 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673516188; a=rsa-sha256; cv=none; b=AWUwwEcK6nKLyqf1eY+4NxWhJXJ06xGq1xBPTd4zLFd59xSesgMCxuYNUjNxMSk6onkC7n CS6a4SgfCKy0/mnSD29f8OAGFrlbzKH0ZpZno51SzXX1WCPpF8lgsIbX0xoCqFPLm6+xpR y5J4pfoitZ4LLIYVryFj6IL5M5ThBYw= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=none; spf=pass (imf14.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.139.229 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673516188; 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; bh=dKTDFV8eYr8kpObrhjLXq1cJBlW9AAEgGJFF4OAPQHE=; b=g0GanOQCG0AprnK3pSPgYN1Q4hxmbgF2dKLzSbXDwjraA0KEbWozUyo5j8u0Cy5FfFKAzN cDleJu6ExC0XSloK8Zf04prR/i0/XoV2V8CvzvJDDW+H5bWnYopp58rnNm9ulwEcdx1pXs hecs5n21z6b7aysCti+pTQKpK8Df8wA= Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp43.blacknight.com (Postfix) with ESMTPS id 2E8FC1EDB for ; Thu, 12 Jan 2023 09:36:26 +0000 (GMT) Received: (qmail 6429 invoked from network); 12 Jan 2023 09:36:26 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 12 Jan 2023 09:36:25 -0000 Date: Thu, 12 Jan 2023 09:36:23 +0000 From: Mel Gorman To: Michal Hocko Cc: Linux-MM , Andrew Morton , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML Subject: Re: [PATCH 2/7] mm/page_alloc: Treat RT tasks similar to __GFP_HIGH Message-ID: <20230112093623.sl4jpqf6f2ng43w2@techsingularity.net> References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-3-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: ABBB810000C X-Rspamd-Server: rspam01 X-Stat-Signature: ow58myckigc9maoqdfku9tec8m4uw15j X-HE-Tag: 1673516187-123068 X-HE-Meta: U2FsdGVkX1+S2zubodb9cJQMHpgPdjPpOyQyaB7p0Lfnc84shAyywqzz3kYsLgrGfPJMosUSXV7Nra1DqmBGq1NgRWs9Dg60D+0h+TNyQauGpifyYbw2OZo2Pov18b5VwVP2uc+778MMoKtQWHWgo5jnotv4trlfCLMDoLAp7wMO2FsT6zhLstp3gKTOfiWzlPadeyew/qoKWfkK5Psft7Mxv01ONP9BgJhSfJsS9ZsVXjej59Zz5qxgluqRVQPVW8R0fNp5BzPCAdLfGYZxyKv7s89iTVzKCb8xmVrvsJeG4BVcaJqjQ8SihExo24DJLwX9X6JDJLZ2Hc6vZZ701yXObHFMF2qx6tELGSlPc5zah4xycbt1zUbtaapFOFy0LUyCGzdnsIkLyInlQwaLzML0htZLu/o9VW9vufc37++zAvbXAWCWd+81iXR53iB4hwAcIO8gtSzms36Nz8l7J98X9E5rFZ/XV08jzAsQIUjF5707Ab34kQYeu6i8tYDDh0zsuiKdZTzJAT6J2A41YUMbpOWuN4RUHxOeSqJLLLU6mnYyayl+5fk6z3iXAov3iTz4f0MOO22Y4VXLMKuMp9lhyoNKCLO8aa3Z12RMv8TQSmpXUz1iYqbTVNmS42juyXfzVFM2Si/SCIS1UdbqbJY2pNZYBy6WV4xWC8Ja/BHyqE5UvYEJNB4hLEKwXaDvOY6cw4i3nzfWjXt+gbgOaoE+NUmLWSQnbuEK8WvarWzN6YqskOzGj02oapWPkSvEAxeSql5VXmUZm9KYHviJprQaljU/cS7bY49IqLSnN7ZfFc53mVl5RD7vwgdUZVMqzgm68IOpoz8tMUIeqboawEewzhEO5CnbZvz0jLJ5GfsbTJePx5Mb7QVXNOL5yPfjNv6clI3tUHiX1BMBPjHFr2rxDG0ZSAipub4kN+iAgjMzDvQuA5Afxw16gB3jOtK8XXq6HpJf5UUgPTNWrDC BFlosxUr KzVrM4FD/mJvVyvDJV3gGadHZDOnyJdrnYzJ+ 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: On Wed, Jan 11, 2023 at 04:27:29PM +0100, Michal Hocko wrote: > On Mon 09-01-23 15:16:26, Mel Gorman wrote: > > RT tasks are allowed to dip below the min reserve but ALLOC_HARDER is > > typically combined with ALLOC_MIN_RESERVE so RT tasks are a little > > unusual. While there is some justification for allowing RT tasks > > access to memory reserves, there is a strong chance that a RT task > > that is also under memory pressure is at risk of missing deadlines > > anyway. Relax how much reserves an RT task can access by treating > > it the same as __GFP_HIGH allocations. > > TBH, I would much rather drop the RT special casing here. As you say if > a RT task need to dip into memory reserves it is either already too late > because the execution is already under RT constrains or this is init > phase where the reclaim is not a problem yet. > I completely agree. I included it in the changelog because I was tempted to delete it now. I'm wary that the series will result in some allocation failure bug reports and so played it cautious. Hard realtime tasks should be locking down resources in advance. Even a soft-realtime task like audio or video live decoding which cannot jitter should be allocating both memory and any disk space required up-front before the recording starts instead of relying on reserves. At best, reserve access will only delay the problem by a very short interval. > I have tried to trace down this special case and only found a patch from > Robert Love from 2003 which says: > : - Let real-time tasks dip further into the reserves than usual in > : __alloc_pages(). There are a lot of ways to special case this. This > : patch just cuts z->pages_low in half, before doing the incremental min > : thing, for real-time tasks. I do not do anything in the low memory slow > : path. We can be a _lot_ more aggressive if we want. Right now, we just > : give real-time tasks a little help. > > This doesn't really explain why this is needed. > No, it does not but I'm not willing to complain either. 20 years ago, it might have been completely reasonable. > We are really great at preserving a behavior and cementing it for > future generations. Maybe we should just drop it and see if something > breaks. We would get some reasoning at least finally. > > So I am not opposed to the patch per se but I would much rather see this > branch go away. If you want me I can condense the above into a changelog > and send a patch (either on top of this one or replacing it). WDYT? > I agree with you but given the risk of bisections hitting this series, would you be opposed to delaying the removal by 1 kernel release? That way bisections for failures will hit 6.3 and a single commit or at least just a report against 6.3. That would mitigate the risk of a full revert of the series. I can add a note to the changelog mentioning the expected removal so git blame will also highlight it. > > Signed-off-by: Mel Gorman > > Acked-by: Vlastimil Babka > > Acked-by: Michal Hocko > Thanks. -- Mel Gorman SUSE Labs