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 C7CEEC3DA6E for ; Sat, 6 Jan 2024 00:05:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2BE256B02B7; Fri, 5 Jan 2024 19:05:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 246276B02B8; Fri, 5 Jan 2024 19:05:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E87B6B02BE; Fri, 5 Jan 2024 19:05:53 -0500 (EST) 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 EC1686B02B7 for ; Fri, 5 Jan 2024 19:05:52 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id AECDC40B31 for ; Sat, 6 Jan 2024 00:05:52 +0000 (UTC) X-FDA: 81646942944.12.6621933 Received: from out-184.mta1.migadu.com (out-184.mta1.migadu.com [95.215.58.184]) by imf07.hostedemail.com (Postfix) with ESMTP id C743D40026 for ; Sat, 6 Jan 2024 00:05:49 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vll94vkZ; spf=pass (imf07.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.184 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704499550; 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=srTL0MzvVyILIQT7wSMgJAQ4spYLZ+uATUXyxB8CAMI=; b=QUOl2hVkjFuwXMftxbPfb/2ytIf3oyTMTY/vWOIIWnica+UGEIkwwKa2JKSDewvoBVQQtj RSJgfiGAQlpiOcSDkA/lkQIuIklWbnur0sSv5OQm5OeEkzNdToWlm/lwF0BnAs5mVL2Yf5 zsX3nObThUS83wY20POtabqNdB0xzFE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704499550; a=rsa-sha256; cv=none; b=qCavj6Y0vcPwehv+TFJa3SMwYvrhIsGjVhjh9YBrlFEUkuZ72jpt4ptJRqW0/7uya9wlCu XqufEWIRHkJKRVV7ax7sb6Zk+DN9DFPCK7Z3RT9RLLOHklFxFpuDR+udYnBSwsfeyMkmc5 Zu66jXEWF83wuZAsdCBHaFXN4QZ8ink= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=vll94vkZ; spf=pass (imf07.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.184 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Fri, 5 Jan 2024 16:05:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1704499547; h=from:from:reply-to:subject:subject: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=srTL0MzvVyILIQT7wSMgJAQ4spYLZ+uATUXyxB8CAMI=; b=vll94vkZ7KCGoBy+DSm2FGUHPLe7uhWa3M5e9kWbXYOTD8wmghLtEkDJ497An8g38hEFWT F7BBQ117s76HZew4lbfxYsV3hDPrEv9RDt/I+rBMrjSQtudAdFO1zCvXlY15F4GcT+6nHX ZqR93w+S8bwZB3wIqz6zI+dGjyZy4y0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Sukadev Bhattiprolu Cc: Minchan Kim , Chris Goldsworthy , Andrew Morton , Rik van Riel , Roman Gushchin , Vlastimil Babka , Joonsoo Kim , Georgi Djakov , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm,page_alloc,cma: configurable CMA utilization Message-ID: References: <20230131071052.GB19285@hu-sbhattip-lv.qualcomm.com> <20230131201001.GA8585@hu-sbhattip-lv.qualcomm.com> <20230201040628.GA3767@hu-cgoldswo-sd.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: jo7nssam58suiycq6cty8gekqr8rfjic X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C743D40026 X-Rspam-User: X-HE-Tag: 1704499549-956444 X-HE-Meta: U2FsdGVkX1/8fHbyH86ZdKeuwmHTHvFCXH97H+siL7Thw4YXtHbhKYsNhdvup1Uz0txCgiQIYA1BXpOK67uXT9xhFCnU6MQrpXeIaCul8p7goijK8LQ/iLyoK3+SzuRxY9G+aHu0FRMZDQzx47e+jOuO7ucSUqIB0KEaqMn2iwzXnGBQclHR4nV0A78ap9RJyvjS59QBm9BaaFNJlTr4KJ46tn56wBT3iRpE/ssFH70oBdb+tvzK7ecieH2nje0Nmm5JG90yiYU2FxC2jAkMZKEuHOrDetglR4NGAH4clnBqI0Srm6KBe7RVcuxSKwVAwOZ8rb8w7lnwu48fLnmG5vuQEX7H0CRWhoRFQA0br8PFvi2bAv5akfVXs/aiPLZgm9c+1eOwpMuY+TwMKFBTaNUV/KXd+vV0UclyDxp0hu3Y12ll1noBCwxXPhUfoNWxkE/3dTTuvsfcMI01s5DpEd//Yxp2QBjzpsC5HB/hXdVC5hs88RGlEsknRks0gxd3IOy0ztVkNwEE+pUVBWTnZ+UOrxxDtVQeULlx7zQbqwLgxDhVQimQn3wMYei06IRGMFwHLuy7xiVuIDUJ4lzXHQNa1taBPgVmZJMRqgpU6e+m3jzAkCRzSrrFd6OMKp5n2tnhr5vBOirmHgzGPRbgXGgfTHX3I5qifo6vvXmH6awxnLOBYyiKoR65jOE2LvNjYay9ry+PvCk8kI8Ml0V3aWy0rThFAYswIgfcZ50wNP1v4H8GNrS9srXcNS4K6bAj984u0J89ba7t5AdLpaA5hyUtMRQq3DNnLS3gf7GSUy1TNSL9EqYmXO+CTlF1ypO1wBkzGDbrWF3G5BaX5eCiDUtgPCM0/jc5c3QDHvQXNnRSxjkHAAvP3M8i0e5aPGY1M2yxopM4u4TKbCP9fXZe1AWp59yZf//LWduRlLec2VWZPJYViz+HxWkE0cpZzfO3kWg9o3T/Bmu9tVZMoov RepWirXh rU/oi0Hu9S67Kio5DtxgMHXcrNtYhbIvWRxrb9r2OMfzApy2fX589v/1shcAAPoKO3WHHbBbr7Zz9wxvCi/vFmjaV7KCHGFlkgh9/KHK/YXlGyiY+g/4Ex94vuBojSlOIpluV5+LrdQ6VgzGR55XhKBdNhqol6oaTdkihmbov0aoaZ4Y= 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: List-Subscribe: List-Unsubscribe: On Fri, Jan 05, 2024 at 03:46:55PM -0800, Sukadev Bhattiprolu wrote: > > On 2/1/2023 3:47 PM, Minchan Kim wrote: > > > > I like this patch for different reason but for the specific problem you > > mentioned, How about making reclaimer/compaction aware of the problem: > > > > IOW, when the GFP_KERNEL/DMA allocation happens but not enough memory > > in the zones, let's migrates movable pages in those zones into CMA > > area/movable zone if they are plenty of free memory. > > Hi Minchan, > > Coming back to this thread after a while. > > If the CMA region is usually free, allocating pages first in the non-CMA > region and then moving them into the CMA region would be extra work since > it would happen most of the time. In such cases, wouldn't it be better to > allocate from the CMA region itself? I'm not sure there is a "one size fits all" solution here. There are two distinctive cases: 1) A relatively small cma area used for a specific purpose. This is how cma was used until recently. And it was barely used by the kernel for non-cma allocations. 2) A relatively large cma area which is used to allocate gigantic hugepages and as an anti-fragmentation mechanism in general (basically as a movable zone). In this case it might be preferable to use cma for movable allocations, because the space for non-movable allocations might be limited. I see two options here: 1) introduce per-cma area flags which will define the usage policy 2) redesign the page allocator to better take care of fragmentation at 1Gb scale The latter is obviously not a small endeavour. The fundamentally missing piece is a notion of an anti-fragmentation cost. E.g. how much work does it makes sense to put into page migration before "polluting" a new large block of memory with an unmovable folio. Thanks!