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 36948C7618E for ; Fri, 21 Apr 2023 15:55:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B19CD6B0071; Fri, 21 Apr 2023 11:55:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ACA186B0072; Fri, 21 Apr 2023 11:55:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B88D6B0074; Fri, 21 Apr 2023 11:55:30 -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 8C15F6B0071 for ; Fri, 21 Apr 2023 11:55:30 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3D89B1A0502 for ; Fri, 21 Apr 2023 15:55:30 +0000 (UTC) X-FDA: 80705848020.19.B0D2A62 Received: from outbound-smtp02.blacknight.com (outbound-smtp02.blacknight.com [81.17.249.8]) by imf17.hostedemail.com (Postfix) with ESMTP id 240F14001F for ; Fri, 21 Apr 2023 15:55:27 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.8 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=1682092528; 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=P+m6I+yUb3OsL/hKno0qMXtMbKTqv1qoj1sAQQYd81s=; b=w1f21SwRHc7ltw+ZMflUx3BFJ6xuEMHeZernLnzOpfltVSvpJCesA0ku499JDqtg0QaQ9e MJA0ufeMgSJRvcPoq+wvI4CYyaIZL/IjVur6WS5Pk6A443FrAjqBNNKWr88Eq7dIkmGP8o L4wCryBH+8tUlVAUs3dTSk+NLzlpXeU= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.8 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682092528; a=rsa-sha256; cv=none; b=QOmR9pdha68s/jtcygOgyXjpjLNl3FiJzV2jEnsg2Y3RQH1Ey9NoeDTBCmVQ+wc5p49l3Y gZAQWezjZJdtkmRhx3+NrqaWQwkqTKar7nqCcGOAAUD1jWb2wUphKpMM9ov5ZLWJZfpNpH aJSuRahzccI0cuLsgnq300BCWLZnZ58= Received: from mail.blacknight.com (pemlinmail03.blacknight.ie [81.17.254.16]) by outbound-smtp02.blacknight.com (Postfix) with ESMTPS id 2A56ABACC4 for ; Fri, 21 Apr 2023 16:55:26 +0100 (IST) Received: (qmail 16126 invoked from network); 21 Apr 2023 15:55:26 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.21.103]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 21 Apr 2023 15:55:25 -0000 Date: Fri, 21 Apr 2023 16:55:23 +0100 From: Mel Gorman To: Johannes Weiner Cc: linux-mm@kvack.org, Kaiyang Zhao , Vlastimil Babka , David Rientjes , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [RFC PATCH 25/26] mm: page_alloc: disallow fallbacks when 2M defrag is enabled Message-ID: <20230421155523.p4qqx23xpwlm3yt4@techsingularity.net> References: <20230418191313.268131-1-hannes@cmpxchg.org> <20230418191313.268131-26-hannes@cmpxchg.org> <20230421145657.fnpjqkuyquy3z24t@techsingularity.net> <20230421152448.GD320347@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20230421152448.GD320347@cmpxchg.org> X-Stat-Signature: fp3gczeuqkuogpzzoj357btz3srr1qc7 X-Rspam-User: X-Rspamd-Queue-Id: 240F14001F X-Rspamd-Server: rspam06 X-HE-Tag: 1682092527-205698 X-HE-Meta: U2FsdGVkX18eh6yTm+6xIYcQFqZQLhJIgt9iElSFHG7KJWurLygGgcdSrJZmgLqeXb5D8BwEj2ssZFDbHYpH4rgePMfP9vduD90+FJ+LLM4uU2+8vBKf4nUHzMUWLu+NJFjsfwzvkCai16AUwNJYw4ytDvwHUGFebisBWb9WKMlcuNMH1R8swRkZPKN5+yBmyr/HWsYzTAfrtaS4GENFO8SCJaZuEl7TFf4tMiKepL+qzaaHzrTjTGyjc+gVHdVJLZ0ipPRWV/V4+VHc5qj3TRMCj3hpyO3gHuGStI8vWVEL3N9HGkKFKTOIXCTIojNLmekpX25QjZaWGzzprzBrB1F6FoZhy7X5rAPpK3NYcnS/o3MBk7gK1iVxfEO6zJxgcBVkroz0SueXxNBs2wjwtQNr0lGIfzkCQlR4vU4fq9rZV5YMWf5AFcbofUNEOC3yc36/FYvT4EP6AuXJ50hyelV+qJ6bo03ga4/USbWIQdW5lT5skxvVTSqFt7LuahLory+R5PJMTDwIHd94SftNsBFcxqeQsYlV8EcurHKI2xsYJzN/dVkuovTtZ18GbSu155MTL+xm+tZjTWM+r+eJPsKkJQtfYsWYnFDecjCdrDJBFT/2Xk0Y0jGPYWRCyTL172Uw7y8PjYUOIaUhHFqrWtp4HpMEQgszeYokxRGLOeyiwkE1dbDmAs7tTBOhqjBu4l99nWNn8hZVHE3skxFrZsTb429yFJSPlxXiU884dJHBopG7hbY6yCSx6eqYCk19tjptiBXNK67GEX7sTNc7dPM418ep2hO649btWndCqr+KMVt8SSp757eJILykkkVx78B31u6vJZL+D7LPYLckvyh9/LUcCIgmHK4/pYxVYI5gupH1DU1NIftQgYbOsljZLgkgjYB2UjD2+NYtzPMv6w4d9d1M22uUJlr2m/zu6+SQ4Ug92MKhBezNT/d5WeEKyC8Qry8Yu7Zj2xDzaxI Wum/7AOp uB9EGqLy4d30sVZJ7/8k9DLOsjaBSlA1vdzky+g2qLmTm9vWqSHBdj+OjaJ16B7sxQHp3BwbyfT4/PjePQQTFwu66Z2gntRrGXVeMFS7QilduHiTbokWMofyfuGw/6c2BvpNZt81oMKbdWRwqBKYx5/rUek9w1np6ymDq2R6GHtr5mN1UbZhj1km16oZ7kJIyRVp9ZzHlnt07F/V5V/GuTV278NX6fZYRMUkP9NPDQarUjyY79KdzF9nLnfhlbFbZhXljWodFqNxAlag= 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 Fri, Apr 21, 2023 at 11:24:48AM -0400, Johannes Weiner wrote: > On Fri, Apr 21, 2023 at 03:56:57PM +0100, Mel Gorman wrote: > > On Tue, Apr 18, 2023 at 03:13:12PM -0400, Johannes Weiner wrote: > > > Fallbacks are already unlikely due to watermarks being enforced > > > against MIGRATE_FREE blocks. Eliminate them altogether. This allows > > > compaction to look exclusively at movable blocks, reducing the number > > > of pageblocks it needs to scan on an ongoing basis. > > > > > > Signed-off-by: Johannes Weiner > > > > Conceptually this could be fun if a GFP_NOFS allocation cannot migrate > > enough memory to free one pageblock and there are no pageblocks > > available of the correct migratetype. Fallbacks might be unlikely but > > never being able to fallback is a livelock risk, no? > > The reserves below the watermarks are maintained in neutral > MIGRATE_FREE blocks. So just like today, critical/limited allocation > contexts are ensured forward progress as long as there are reserves. > > An argument could be made that because smaller orders type-claim the > entire neutral block on allocation now, the reserves can deplete > faster than they do today given comparable watermarks. I haven't run > into this issue during testing that would have me raise the reserves > by a factor of NR_MIGRATETYPES. But something to keep an eye out for. Also bear in mind low memory systems, not even the embedded ones, just things like a cheap laptop with <= 1G. I haven't consulted the code to think this through but forcing watermarks to be in multiples of pageblock could be get trickier the smaller the memory size is and it would have to be considered what happens when min_free_kbytes for a zone is smaller than pageblock*MIGRATE_TYPES. It's possible it's protected, or could be protected, by page_group_by_mobility_disabled but that only applies for very small systems. -- Mel Gorman SUSE Labs