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 600DDC77B7E for ; Mon, 29 May 2023 13:04:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B2872900003; Mon, 29 May 2023 09:04:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB162900002; Mon, 29 May 2023 09:04:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92AF0900003; Mon, 29 May 2023 09:04:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7D539900002 for ; Mon, 29 May 2023 09:04:08 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1216540159 for ; Mon, 29 May 2023 13:04:08 +0000 (UTC) X-FDA: 80843310576.19.E94D967 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf16.hostedemail.com (Postfix) with ESMTP id A2855180010 for ; Mon, 29 May 2023 13:03:56 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=AvJfha7P; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=RlzNCcpo; spf=pass (imf16.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685365437; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Tc5kSCmE2FMssHmpJJAR9HCJO9j6BfEH8BHbYAEXixc=; b=prx9KyYlkFG26igM5nury0FHYsw/Fl8wu8lJuCBM6HjSW3Gw7Ed3PIFytf0mrxRqJNs7sx n7gQuwtpci2GOxUBKpTlrwH/a5lbtfp78i1tnYlxpA+x7nvO8agZ0uXiwG1vmEPtSPJ2NN HsY2YBk8moY65so16rr3qh3BQMGv27w= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685365437; a=rsa-sha256; cv=none; b=0qidYrDdojNM7QfsB7i2pAABHg4koZwsYQhMmatpuV20NoEzCiFriDRR6WI0zHUwJRH9vb R4xNY6liqDVjREtPuIy8UyuH7bZIlu2GuJmb08gIb7gYZk3v9kkpMpU/wPj6ZRZM5q00mM o+76hKgIhLahdgg3DkJ3RUW9RogVIlg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=AvJfha7P; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=RlzNCcpo; spf=pass (imf16.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none 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 568761F88E; Mon, 29 May 2023 13:03:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1685365433; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tc5kSCmE2FMssHmpJJAR9HCJO9j6BfEH8BHbYAEXixc=; b=AvJfha7PIKScylt2Z/almeX1F5TD0fU21Msa+qwAegXte80G6b+8M+99OOrFz4mt/SNK0s T+gYD9w0lREPEW6qTnacnociAi7VKwntYyTsMPmYIpIGp+ZgzNAOtppIJZHHXvCKUtKm2j bB972uronf/uWmCr7PlaAPVTGTCQJ2M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1685365433; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tc5kSCmE2FMssHmpJJAR9HCJO9j6BfEH8BHbYAEXixc=; b=RlzNCcpoH9Y2NmrGJQX69OAIR5iUyDmtNTwx5iyWcDylK+hlLd9CetIRX+rGGWRCbxYqC6 z2wTFHg3E44wRdBw== 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 3297C13466; Mon, 29 May 2023 13:03:53 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id NyL/CrmidGSaIQAAMHmgww (envelope-from ); Mon, 29 May 2023 13:03:53 +0000 Message-ID: <1c3c9305-a678-279e-f015-7aed544ab3c8@suse.cz> Date: Mon, 29 May 2023 15:03:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: [PATCH 2/5] mm: compaction: simplify should_compact_retry() Content-Language: en-US To: Johannes Weiner , Andrew Morton Cc: Mel Gorman , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com References: <20230519123959.77335-1-hannes@cmpxchg.org> <20230519123959.77335-3-hannes@cmpxchg.org> From: Vlastimil Babka In-Reply-To: <20230519123959.77335-3-hannes@cmpxchg.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: 78mh7awayhqa7ha7urwsh3ysyyhx8ziw X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A2855180010 X-Rspam-User: X-HE-Tag: 1685365436-404787 X-HE-Meta: U2FsdGVkX1/KQT6ayOe08v+fohOLzwiU3g3f/8OwQRm3v5OIPMtJPSt61SlGrnMx+GPq39k16UfO9a4+L6l2p9AVB1p+tH70TWpwZqoszyYWhDlFNgzAW/zGz36x6NYWrTdfunoCfPOp3c3X+sdTpJ+8qi/kU+60QpK3JL5OJhvnSH0EGhz6KGUs40qf1/N7p5YfDDRF8RtMa5O/E1s2mNEx1Jt9MfriBqb+kb+gIE6tK6cOtq6YtWslacPQM0wJOoPC/hz2GTS90L7dgVNLVMxm/5NowPN9yFOWi7N3f0JHCIWa0ILXuO45QZwfYubHwbIcHCCO4jb+y95xpgMqi4xZJBkKNWTM6JUXWPmxcxVizEWGLUYIMKSsyGlnHteTUKBDMnb4v57Ps+xIG+siD6+8PoFQUiRRpfbRMsQ1h8WSj6INRt33QVI4p2Ak8noIrmCYVI2S9pz4nCUfE7Zd0tegq2LyhfdyhjtT78vsU7Qe4LXksML7z/J3xvD9jW0/Mtr+kNyk9nUZqDkEZ7A3KVk2WD/P3c6Tz+MdARwNO3g0NMgkMPSMzNPm+J5lC11u87qtvYVhuv6w2hnKqU1NMQrkbX06NjdiUvpHxjxQnYusd5XxZfxMQFBWwnFEkA5peowMmwV1m86iHLEGB0JaTlROBftGY22BxQzczqjPEH5nLdL7Q3HtP+H/rWpjE6wqxloHIE18CQtB1LVOK+BMdmA5kx0zom+umD5JhBs3qzW0hz1q+rjWa+CqAcxF/EtFizKrnZ6I7Cpvrpkt90u2VKpoCzp2k43l81KVro2zgsI7e9coGvH0BkM1wbeeHt2vTUQodPMTX7Q7jFExAjP4xjEkgmbbYGzSMcWaKSH61uJqk39A3YjQnQ26uT1UgJbM02ksGNQz/AUJKIvMAUprxhDHIeToKFyYVWxXTMlldb+bh4zBTfFWj9ySAcN8ElnmeF7l7PlgmcORCUfU96q osc7+avC vQDiwBsUV/pgnxHK1Vds3AbtI0XmLLykL/pfwhC3OrtVhlim8fH1v72LRHqYJe4lBMCDuXADkSLqrnJ48YcihTgErHYpC/ssBDocLTXFUFEh5tkLNyniLChY/DOwtRi3owrB6icn+lS/ScVK038hmiHdrVFi2kwawvmGUuhrxL/uNL9yO9uRgCT1ex3GBzjvzuPlZlTzTprNQ9TIwdFO8ce/UOksAnMsRIiTAAwxiBLrrbpqSP8tNbpxSXR8zqvAYFRC7z+pQ778rUHytGdHQC2kTEY7mL0fSXimD/iUBc9zcQrg= 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 5/19/23 14:39, Johannes Weiner wrote: > The different branches for retry are unnecessarily complicated. There > are really only three outcomes: progress (retry n times), skipped > (retry if reclaim can help), failed (retry with higher priority). > > Rearrange the branches and the retry counter to make it simpler. > > v2: > - fix trace point build (Mel) > - fix max_retries logic for costly allocs (Huang) > > Signed-off-by: Johannes Weiner > --- > mm/page_alloc.c | 53 +++++++++++++++---------------------------------- > 1 file changed, 16 insertions(+), 37 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 5a84a0bebc37..72660e924b95 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3772,16 +3772,22 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, > * Compaction managed to coalesce some page blocks, but the > * allocation failed presumably due to a race. Retry some. > */ > - if (compact_result == COMPACT_SUCCESS) > - (*compaction_retries)++; > + if (compact_result == COMPACT_SUCCESS) { > + /* > + * !costly requests are much more important than > + * __GFP_RETRY_MAYFAIL costly ones because they are de > + * facto nofail and invoke OOM killer to move on while > + * costly can fail and users are ready to cope with > + * that. 1/4 retries is rather arbitrary but we would > + * need much more detailed feedback from compaction to > + * make a better decision. > + */ > + if (order > PAGE_ALLOC_COSTLY_ORDER) > + max_retries /= 4; > > - /* > - * All zones were scanned completely and still no result. It > - * doesn't really make much sense to retry except when the > - * failure could be caused by insufficient priority > - */ > - if (compact_result == COMPACT_COMPLETE) > - goto check_priority; > + ret = ++(*compaction_retries) <= max_retries; > + goto out; I think you simplified this part too much, so now once it runs out of retries, it will return false, while previously it would increase the priority. > + } > > /* > * Compaction was skipped due to a lack of free order-0 > @@ -3793,35 +3799,8 @@ should_compact_retry(struct alloc_context *ac, int order, int alloc_flags, > } > > /* > - * If compaction backed due to being deferred, due to > - * contended locks in async mode, or due to scanners meeting > - * after a partial scan, retry with increased priority. > - */ > - if (compact_result == COMPACT_DEFERRED || > - compact_result == COMPACT_CONTENDED || > - compact_result == COMPACT_PARTIAL_SKIPPED) > - goto check_priority; > - > - /* > - * !costly requests are much more important than __GFP_RETRY_MAYFAIL > - * costly ones because they are de facto nofail and invoke OOM > - * killer to move on while costly can fail and users are ready > - * to cope with that. 1/4 retries is rather arbitrary but we > - * would need much more detailed feedback from compaction to > - * make a better decision. > - */ > - if (order > PAGE_ALLOC_COSTLY_ORDER) > - max_retries /= 4; > - if (*compaction_retries <= max_retries) { > - ret = true; > - goto out; > - } > - > - /* > - * Make sure there are attempts at the highest priority if we exhausted > - * all retries or failed at the lower priorities. > + * Compaction failed. Retry with increasing priority. > */ > -check_priority: > min_priority = (order > PAGE_ALLOC_COSTLY_ORDER) ? > MIN_COMPACT_COSTLY_PRIORITY : MIN_COMPACT_PRIORITY; >