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 E8A98C46467 for ; Wed, 11 Jan 2023 15:27:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52F0D8E0003; Wed, 11 Jan 2023 10:27:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B62D8E0001; Wed, 11 Jan 2023 10:27:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 357008E0003; Wed, 11 Jan 2023 10:27:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1FE8A8E0001 for ; Wed, 11 Jan 2023 10:27:34 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id ECAE4160854 for ; Wed, 11 Jan 2023 15:27:33 +0000 (UTC) X-FDA: 80342897586.20.2A82093 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf27.hostedemail.com (Postfix) with ESMTP id 1567F40021 for ; Wed, 11 Jan 2023 15:27:31 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=j9o3aXue; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673450852; 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=G1eUl4jxJDNbdWQ3YdpoRYPsUON8AwuxLmE+58zdEI8=; b=JlSLcXbA0giyM7B+Ih+H72ZUruYQAUWN1tb9+afIB4cwIsT/D4yIl5KGExc7sSVLjsYeed L6S1gXor7vZXx4NNxMsC60f4k5S80BqpuXl6PpNwqhHIVnX1O+Tij99g1I2sa3Ft+bhQFR ix9Qp6IYJeRnJFElxRXgS4HR4/1Leb8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=j9o3aXue; spf=pass (imf27.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673450852; a=rsa-sha256; cv=none; b=Gh4/SYif5Qq9EtJ47mXyJGm8eGHquGxcXtApKlzq1pjcUUF0UHAbSjt+Gholzmp9Y3TnOf ELuJPBRo5Pyv/ep2Y1J4fdpTTFY7gBmeBxyIR2zV85l38xLCh1xhNcPxe1yTs4t2dP74HR tDLtdl3gROcHDQvhU/JlvsH3BLkfYgY= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 281B94C5E; Wed, 11 Jan 2023 15:27:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1673450850; h=from:from:reply-to: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=G1eUl4jxJDNbdWQ3YdpoRYPsUON8AwuxLmE+58zdEI8=; b=j9o3aXuenBDvWzcYcaXN+hiTaQVHhxazS18bRxTnhkfYvi5JOhSgtrg2Hf4e+Xqi04fKmd TuNi+rPP6LqMjUIZdAfUDWXLdjuX5xo6zLWqYmipOMkQAPMH/wvnftojVMgIcXKOn+ksD0 c6o2yKb0HBTj4rxsT7BodMlgkh0S3Hg= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 069ED1358A; Wed, 11 Jan 2023 15:27:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id t2vqOmHVvmOvMgAAMHmgww (envelope-from ); Wed, 11 Jan 2023 15:27:29 +0000 Date: Wed, 11 Jan 2023 16:27:29 +0100 From: Michal Hocko To: Mel Gorman 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: References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-3-mgorman@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230109151631.24923-3-mgorman@techsingularity.net> X-Rspamd-Queue-Id: 1567F40021 X-Stat-Signature: 9pxowmdkd46aty13ib19nmgkaehnhybw X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1673450851-20861 X-HE-Meta: U2FsdGVkX19gdgimX/0NQwvOxRQNo5q0bPvEXp3kSANr5QsZCU+3Aj8ccA6gSMosB4Ke/62M6FvNet2sssn9U1bAICbRBPl1zFI0gT0giXBIvKsSGxi7mmL9Dw/XI2lRICAPXTSBV/IIxOVNBCYW8KkkwmPrZc2r9bL4qMOakBROa1NeYS8qExXrizGAGHSv+TiK/JKLgFb4AbF+4UdVroMWWxBSp+irr3yWlrfGoUxaHD4ML6ejaq38Mvpxj9KVfg7l5hRR653McuOa3qiipOKsaOgvBdDvdjpS7log/ndgFwXRWQxv086++AcKcilpiDxZSNzZo76u3W8c5wwIAWAwgWtkxEeLQJhMdBeXgUajhcjwXKNrD8rQtjyfaJ/YMIr7QBbhg0C0m7Dmyr0b7iwabME8GQ6w+Y+p0ItIoJmJPp+IbMvgW0WdX1sBG30oYaJX52QgVBboPKsT58X/J47yLtnNLnB4GAIQFreQwOGQzYAnZA40P2CMk9HW8U/wa/eUzEWzKoMBKA661jG3/e+tPU9+Ul3UYUhPWwsYCJtd8X+G3v4Pe38zjfPJvN3TaMs4RbS3gIEnZcnEEYHqu7J4oIZOBZ2ClocB0YqxZvF2bN0OnAkW7o75WAL5Ty9BBRnM5ygVrWOv+vGLI3ajIzyVoqHQlqGi5oUWD2j/J9Ec/fJ0vYXeXCKDZ4AJ6RltRNFP3dotykH3mj3EVu4BZyLv2957t6+BW5fTuLJvYqZ6aMeRPM3bG72NiS1qT3ic1TuSdh4D8XRi6sCe2mn5BGty71GQB9J0Tu1jU53+epZ+B/xcCpVzwsu/xkNYI6PcBgFbaRJimyMWqB62nKhcojjcAOGbBzbpUSd/llFDDPgNOUmANXi9Me/zMepXBebs5Vt4QGRVS4qEnOCMh66bQH+8DmRal3LmKP8JheAX3Iu740znatKM7T2eRA6txA21MNtzF/eRT73d0I8gBbc 3xECk8MG b3mK/pMQMSlmPq9w= 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 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 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. 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? > Signed-off-by: Mel Gorman > Acked-by: Vlastimil Babka Acked-by: Michal Hocko > --- > mm/page_alloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 244c1e675dc8..0040b4e00913 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4847,7 +4847,7 @@ gfp_to_alloc_flags(gfp_t gfp_mask) > */ > alloc_flags &= ~ALLOC_CPUSET; > } else if (unlikely(rt_task(current)) && in_task()) > - alloc_flags |= ALLOC_HARDER; > + alloc_flags |= ALLOC_MIN_RESERVE; > > alloc_flags = gfp_to_alloc_flags_cma(gfp_mask, alloc_flags); > > -- > 2.35.3 -- Michal Hocko SUSE Labs