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 1144BC54EBD for ; Thu, 12 Jan 2023 08:29:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A8768E0003; Thu, 12 Jan 2023 03:29:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 931988E0001; Thu, 12 Jan 2023 03:29:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7AB178E0003; Thu, 12 Jan 2023 03:29:21 -0500 (EST) 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 68D318E0001 for ; Thu, 12 Jan 2023 03:29:21 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 24DB3C07D6 for ; Thu, 12 Jan 2023 08:29:21 +0000 (UTC) X-FDA: 80345472522.11.70C789A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf06.hostedemail.com (Postfix) with ESMTP id 631A3180007 for ; Thu, 12 Jan 2023 08:29:19 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rju5r5uu; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 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=1673512159; 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=5VH0SSGFS8gLEWMAtHGdpQy2KAVnqJMHbpXMbT+8zf4=; b=fIIPra/ym9mjDL9nG2ipFdCACF8pNDgfHORy5i39W3l3MenlBgTOFjz0gGTzXtYwrcBDOp lsg9drDkzSF2NeUldzA9Kyg26RRXYcNHrUFPeDaH2wI+OjYBmojmJm+6CVmr3wzyAvfqTG EW+FJREf0/gA17159LgU+Sq8Z1EV51k= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rju5r5uu; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 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=1673512159; a=rsa-sha256; cv=none; b=fUwJwARYe18txivIfSaZIZBGrskFIoW+cw2O8PExJUun6QU0P377SzyTSMvj6Lpe6sFqkj dnQk+eDDJYuW/lhgluyo/CugM4fFPIsefD5PNQ3LeOXiMUPvxd5+3r84dEEIWzLA+0OsKj lrZpZ1FWvBJ13rsOhcnNRXoRWQeV+RE= 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-out1.suse.de (Postfix) with ESMTPS id 0FF423F708; Thu, 12 Jan 2023 08:29:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1673512158; 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=5VH0SSGFS8gLEWMAtHGdpQy2KAVnqJMHbpXMbT+8zf4=; b=rju5r5uuuZxoHgc9SRA2z7PYJaGUnKEQv+2bqE5wg/h+o5YW25fAff+iY3ia7hp8tD0oPf pEPYq3fU5cRMkouNwV2Yk9S6ZqJMegBLY+vRvufj6VHV9rDM3FuDwnON2YgCOD6n0opPrP 2G6t3P363VhuQTca2Sauq+Vk7Ih73n4= 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 BB7FD13585; Thu, 12 Jan 2023 08:29:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id vdCGK93Ev2PrcQAAMHmgww (envelope-from ); Thu, 12 Jan 2023 08:29:17 +0000 Date: Thu, 12 Jan 2023 09:29:16 +0100 From: Michal Hocko To: Mel Gorman Cc: Linux-MM , Andrew Morton , NeilBrown , Thierry Reding , Matthew Wilcox , Vlastimil Babka , LKML Subject: Re: [PATCH 6/7] mm/page_alloc: Give GFP_ATOMIC and non-blocking allocations access to reserves Message-ID: References: <20230109151631.24923-1-mgorman@techsingularity.net> <20230109151631.24923-7-mgorman@techsingularity.net> <20230111170552.5b7z5hetc2lcdwmb@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 631A3180007 X-Stat-Signature: 1wgktus4grjcaww4xhjhurunkpi3kara X-HE-Tag: 1673512159-807454 X-HE-Meta: U2FsdGVkX1+noeGi36Eo6mSp1tg/8iiahI1xiXvQVSkr76QgPQYrRsoMC2jrYxInENOVng5V9e9dIsFD/6lwCzL5O5+m6juvbPLpuEtfcWNosjHjBCkgkHP/d/aLHjEDHQDrQe+oZnref9Y4GQwCv/qUCDwLd+ZBt6X6HxMmPX2guYXSBiZMpsh4m22/Ek0fIv91kZXnhcDKxkrR7LebFMUY1d7laEZYVlfOiY/RcEQdXaUOKpTgB/L1JtZcsetqcX0syTip6owSg1BdWfolGqsW2OoQElrc1tp1fQS/INSGuaYaH2dGCoQTMLIt2u7JjLy7mcD5Z7dPpCQmT9jH5vsSCFseKP5bzytlKCiCL+dHU4JG/13VA5ppF/6k1ryu7u7vspqDODTBUGcSX5rfsXlvQ9FAlur7l0wUzD1mRerRIP0+3oQ2EDOjE+oReIgu36YlaKJ4/8Fv2VgE2s+LFVAvbp6s6k7ZTWywZW1DMDiO8g3RUOTkcXxk6oYmoGLWhwji8xEKME/fmjDsH/mY0aTZAjjy9i8cb6y3OG2uNkbR7a02f5kdDzGDH9qyqiDOlzlE7HZDinkJ7bZ9txtNt8iBJabZFslHAK55nIC/ehUeQsE/K/LUHHS5gq8z6b37oOhWRQXIXSw+9GWjyzIjZkZ9Pwxsf2uAywDvC98JH9D9bLMVoWeqwfVMiGW/p3c1YSkoNUpZ9YFZeL+Vq3i5ezulEGgzXMj244cFTmsS34uzd/XeM/R25xTLvBiCXdp7ohd0kqGJVmbNyKECQvMiCmJsoxpcTqGGGrcWCnG/DBgqsGd43YuFhOqaxy1+rMZyzp24sz+ngr5ypLqExiRff7bYfdtzxuUxnfp7JUsiBc9BVoFHHXaUKEitBeWLfkthlrUqFOBqbLrkX/MTj4iyXXElc+7UcfTf3s3h/FnIcv11gSbc+IPatwyScqQ/8yxKPh05S/b4n8OmXALtw5C X03YlzBy XGz2IYQKmVJ/f7cc= 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 Thu 12-01-23 09:11:07, Michal Hocko wrote: > On Wed 11-01-23 17:05:52, Mel Gorman wrote: > > On Wed, Jan 11, 2023 at 04:58:02PM +0100, Michal Hocko wrote: > > > On Mon 09-01-23 15:16:30, Mel Gorman wrote: > > > > Explicit GFP_ATOMIC allocations get flagged ALLOC_HARDER which is a bit > > > > vague. In preparation for removing __GFP_ATOMIC, give GFP_ATOMIC and > > > > other non-blocking allocation requests equal access to reserve. Rename > > > > ALLOC_HARDER to ALLOC_NON_BLOCK to make it more clear what the flag > > > > means. > > > > > > GFP_NOWAIT can be also used for opportunistic allocations which can and > > > should fail quickly if the memory is tight and more elaborate path > > > should be taken (e.g. try higher order allocation first but fall back to > > > smaller request if the memory is fragmented). Do we really want to give > > > those access to memory reserves as well? > > > > Good question. Without __GFP_ATOMIC, GFP_NOWAIT only differs from GFP_ATOMIC > > by __GFP_HIGH but that is not enough to distinguish between a caller that > > cannot sleep versus one that is speculatively attempting an allocation but > > has other options. That changelog is misleading, it's not equal access > > as GFP_NOWAIT ends up with 25% of the reserves which is less than what > > GFP_ATOMIC gets. > > > > Because it becomes impossible to distinguish between non-blocking and > > atomic without __GFP_ATOMIC, there is some justification for allowing > > access to reserves for GFP_NOWAIT. bio for example attempts an allocation > > (clears __GFP_DIRECT_RECLAIM) before falling back to mempool but delays > > in IO can also lead to further allocation pressure. mmu gather failing > > GFP_WAIT slows the rate memory can be freed. NFS failing GFP_NOWAIT will > > have to retry IOs multiple times. The examples were picked at random but > > the point is that there are cases where failing GFP_NOWAIT can degrade > > the system, particularly delay the cleaning of pages before reclaim. > > Fair points. > > > A lot of the truly speculative users appear to use GFP_NOWAIT | __GFP_NOWARN > > so one compromise would be to avoid using reserves if __GFP_NOWARN is > > also specified. > > > > Something like this as a separate patch? > > I cannot say I would be happy about adding more side effects to > __GFP_NOWARN. You are right that it should be used for those optimistic > allocation requests but historically all many of these subtle side effects > have kicked back at some point. Should have looked at git grep GFP_ATOMIC | __GFP_NOWARN is quite popular with more than 50 instances. -- Michal Hocko SUSE Labs