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 AB8F8C001DC for ; Wed, 26 Jul 2023 20:06:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2C438D0001; Wed, 26 Jul 2023 16:06:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DDD9D6B0072; Wed, 26 Jul 2023 16:06:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA46C8D0001; Wed, 26 Jul 2023 16:06:25 -0400 (EDT) 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 B8B0C6B0071 for ; Wed, 26 Jul 2023 16:06:25 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 83238403BA for ; Wed, 26 Jul 2023 20:06:25 +0000 (UTC) X-FDA: 81054845130.15.D728ED1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id A8D9A12000E for ; Wed, 26 Jul 2023 20:06:23 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=2IXrfCmJ; dmarc=none; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690401983; 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=Fpzjs7Jgze9McVogfa/4+ch0fp7gUj2dDPLtv0459+M=; b=0SPPfv8qjF12Dqb2qR0eDdpFFDG8JLyuzpLySnjDI5FkHpNcN/NcRI6GDH514vi/9agTwg 9ojcEvZlhSCLOmCNlne7NcXy8myjY6FXVPJ5wDD1xJBJRL8r9YUHeNeJI7t5BRG3AhvPNm REhQvQtaQWORMIspFliaAq4JX+hIWIA= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=2IXrfCmJ; dmarc=none; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690401983; a=rsa-sha256; cv=none; b=zwjW59bX51sb646eKpQs9JedVDNos5pKsWdDpVST5buLeJHELz6y31PHbaHLd+sn1HXEKK UJiwEsQQd2gojwkwu6rPswwRpv3tJiVOqfe38P6VvLE3jsJN5wLzDQftkmFMQMBJg0nppD Xk9KJ42IKmvlpMARi6Fus0sfKUDNDmk= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A4F0D61C50; Wed, 26 Jul 2023 20:06:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5203C433C8; Wed, 26 Jul 2023 20:06:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1690401982; bh=AZeY2z2NgjtDYunEIr50xtoXJGuiXouk66tb+dsJ1MI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=2IXrfCmJqtltWZGEj/Lku8/N3y+UngB1KKljhSCAnveW/mCwPRDhYaGnKkxap07lq /tVOUwWYwVEaxczH37wPjqTlIO0YJm1hjkSyqGRrmPgwzMnbes1A50U/J/N0H4HY0B 0MpwG6XlHXzCBaq2H3pBgB8lT9ik2s0Y3rxFi/I8= Date: Wed, 26 Jul 2023 13:06:20 -0700 From: Andrew Morton To: Johannes Weiner Cc: Vlastimil Babka , Mel Gorman , Roman Gushchin , Rik van Riel , Joonsoo Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhaoyang Huang Subject: Re: [PATCH v2] mm: page_alloc: consume available CMA space first Message-Id: <20230726130620.7cd312fdd07722f6050e8bb8@linux-foundation.org> In-Reply-To: <20230726150705.GA1365610@cmpxchg.org> References: <20230726145304.1319046-1-hannes@cmpxchg.org> <20230726150705.GA1365610@cmpxchg.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: aoidinjzoygshb8gybt3puerx43ifgwu X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A8D9A12000E X-HE-Tag: 1690401983-222117 X-HE-Meta: U2FsdGVkX1/yCAyQGF6e4rUQGqUh8nl5aAAE9BH6n/2+cNxSy0VUb3qVmAYSJX11ulmlJZw0Vbk4gxcTx7sc/tkK/ewhtYh13q4exT+fuxGrNM0U236oNtDK4TTM836KAKrS/tlhYAxnpQh9V/9TzI39GQaB2AyGXtivysSBP2G9gKcgjEy1SCVpqICnCNClezKCmobCfCq8ed6WwCd1MR6TUFpswxJUOl7wuZBa2Mq+ocLF43QOnwUpLoF0LWcu05DxBn+y1ONV0XKxk4Y1MTs+v8DnauQ3Y+0srF8v6hjQ5P+2r9OOEZgzyy31Efr2zEGU0oyapJelRSsZI5v0uwmu7SpG2mTYD0J+XtO1DAeymlNT9RRwnqlWm1Y6AAl+8LYd0aIJfsTGl1tX3I01lhWBT+T4T/I8N6ztU2BdmsuxAjVwWm6GFl7lXAQB6J4q681f23yfcKJ4AK3JcH3iMtwfXKgNbxq0xxT3qNQ+VNcCvKTjeOnjd7ljj14bQJ08zBS7OEtoNacV04B67XxVS1zeI821ko7o+NhShecp7n8xLlEPwGhFdfKBmWbJZHYQaume/n/lDzxWTuhRECC9V+H6mrwI1Xf3klzieRWzcy2JncXoFj1KUEuqbzRsxVrCeIGGGb7UnY6YjNeL0PA5KoPEZzpOqNPdNPbQwSu7l5WvlW+LM/q+Z7ff/RD80OY+Q40LbGUkZWLPCp9uMM6Z1m4/4mUIroh6V1sSkYfpgc8yNCPHEIVVBuYjo2/SZsXwww/UpaRPRLsEvOpgbJmHPgycxAkacHK0v0KM9KkveL9gZuwO+nHdWBAQyfrsWFej3ah0a3SzGdErUHhFVfzOKaEkDIpvJO4tnXF6oBLN5YyT/BaBaiqcHpGHs576BzRr2UwWmT4d0SFO4tnxNLk4WJHa47JmIuUITLqjsJwIDSMmpjRiqkng9yZtCCAhvmtY564mwPAtOOjyjXUqYYm gdyEqt6K 0fk08iud7X5wOJ/WbeLJj9l1s8szn0LVeXuanN8sUwefJtomY/5jFnsxGePKrDLdMiO0d8cWeuNChuppr4qmESxBplCHA3xtsB/dNywnYu913H14ccFzasBG22SxK7cfU2+Ua5gB86erQnBpD6NHNQhy1BmP1Frdf+AQPHlWxuGXx3C90zoHnaqPgorCf82IQ4k+2uWHOosTm79qrdxukDvb+0RjKx2jRAL50xSeATus4Gz1jymg9LDOkzEX58p9dV9+JDt/+vPwEWGFLr3xH7qDdttX4XG3RVh/Zo4YbnYzSHbvXYvRQciK1UJC18FxNf7qLqztj5ANsjkve7KVfM11dQyCgIa2Etny5qrgZEhQm71lXn6ZhqErI0yyngpU+roM8i4fqLeGYw8Q7F1fWa61MrxtkzHtzJjrMqM1MHl4e3AqX0U0mIjKLGg== 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, 26 Jul 2023 11:07:05 -0400 Johannes Weiner wrote: > On a memcache setup with heavy anon usage and no swap, we routinely > see premature OOM kills with multiple gigabytes of free space left: > > Node 0 Normal free:4978632kB [...] free_cma:4893276kB > > This free space turns out to be CMA. We set CMA regions aside for > potential hugetlb users on all of our machines, figuring that even if > there aren't any, the memory is available to userspace allocations. > > When the OOMs trigger, it's from unmovable and reclaimable allocations > that aren't allowed to dip into CMA. The non-CMA regions meanwhile are > dominated by the anon pages. > > Movable pages can be migrated out of CMA when necessary, but we don't > have a mechanism to migrate them *into* CMA to make room for unmovable > allocations. The only recourse we have for these pages is reclaim, > which due to a lack of swap is unavailable in our case. > > Because we have more options for CMA pages, change the policy to > always fill up CMA first. This reduces the risk of premature OOMs. This conflicts significantly (and more than textually) with "mm: optimization on page allocation when CMA enabled", which has been languishing in mm-unstable in an inadequately reviewed state since May 11. Please suggest a way forward?