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 2D43AC3DA6E for ; Tue, 9 Jan 2024 02:59:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 841996B0075; Mon, 8 Jan 2024 21:59:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F2DD6B007B; Mon, 8 Jan 2024 21:59:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E07C6B007D; Mon, 8 Jan 2024 21:59:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5E9C46B0075 for ; Mon, 8 Jan 2024 21:59:37 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2821B80199 for ; Tue, 9 Jan 2024 02:59:37 +0000 (UTC) X-FDA: 81658267194.14.900F00F Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) by imf09.hostedemail.com (Postfix) with ESMTP id 28C46140005 for ; Tue, 9 Jan 2024 02:59:34 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=asguh6I+; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf09.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704769175; a=rsa-sha256; cv=none; b=MEgaDcORrmLJdmNzofVpG7sfhCfnAvj2FAAA5de5eNdSt/rCoMzax85LEvlGvHX9bHQWwa qfI1q4ufih5x61KV6tVlAJyxdaULmceuXU2unkG4qzG7ctDeJm1NWJPj6Qc9H0F2xbLimD aeKLRWMHdG93x/zbCfW3pGuUoG06acA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=asguh6I+; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf09.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704769175; 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=az2DbloPvptLGPocf4LwwB3VnB6zIJOBfZxKs8IGge4=; b=7xaxGE/e9FvX95RFNDymucce5Qvakb54FfUsw/TnWmxO2rC6q6XX4NELBoRVjvcQOQmcaZ 8NPjXySC59qadTsLm1lphPv2H3kvhmgn5aPUxFsBjVAJ1ibtGnfHpeQ/3PitPPN/cnT0zB 8RhLAA8nBW1JxXEaN6K5nZ0xfP1bUzs= Date: Mon, 8 Jan 2024 18:59:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1704769173; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=az2DbloPvptLGPocf4LwwB3VnB6zIJOBfZxKs8IGge4=; b=asguh6I+FXzW5501V/WBdY7tt240i1gZsdScbLKwUFArc0vqJ0JccSkhU18TwzFFsAH5FG eSqZA4hgx20YzUqTBRVoKWJ6ACi/LMgAy2mV5GxGIXdiNCmwe6ArM6oUIFsfLScV2gyKET GEya9crCs5+sOySE1K5jxrgYrp7woIg= 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 28C46140005 X-Stat-Signature: ati8dzs66xrtgy3wuqyxfpsfa14kaww9 X-HE-Tag: 1704769174-486743 X-HE-Meta: U2FsdGVkX19oa/zbufxbQ86S1fcqhg8WXV4K0jotR+5SZBlgEjrfqK89aH9xIr2A85xeyoCtFPm5VGyJXPzNdBqhlzF78VTdLUXULqCaLjA0JZJ2IAGSfpW1h9Wr0z4QTr831cEl4L4SwfhyGI7SnsT6OxKQYEvXm1dUCr4c9uoySTKNRHLWSltxdydci5II4dMYJv1X7SHIh16D4YIbYFKJwibWuu8V5RFif6bRuHrZVHtYREhaeMOaqaRfFU7r7WnRDXzSzd3AM3rJUFCtLvRoepxyojtrNxMeYQSMCz3Osbkg4If8RvQFJEapBVVI/lS9jvvl1ZhP8eFXE8FvMTxqbgEsxieUyYhmlY7cq0FusMCTYCsojy9jrbeOGHZ8Z0Kgk1UU0tImNHOpm/eAeYcdgeEyE1hUgrkPqzYJHsZWidUSlAWpPD8Yk+B3QCIGmFdkyNmfS1e93hF0Nbl+v6KjWlYhdL0hjkrXQGbOOYN04Ca4LCeTbOrV4lkzheRv1ZVI7XDfXlpzTHhsh5516QrHE4tgK8miWoelQJwdDcss+iXK87fMRc0qSSM/0U7cctLRqvaVvh5khP3dVw0x1KP1hKlwb7Mjurr52Ix3An746HDgIWwuOt1TjsQaGXwxGq6jBCVPu7UrC30t+dNZ+bmXrpIaGlryvyh7hx9Uj37mZFlkUYCgN0AkcJOwAa87U8DRUiHAYM5WMFkXSUjNvLfl5GBQOal8I7wrJ2KxtSmwa3F8uqt26E+E+RguuNT+TGmnk8smRkXdZeLjZWSzxV8B4Xr1DmvhCJyJEo9shaw6V9QMJ0RHsy+pzVc4CjdAKXZ5BBVW0JS4RMEJn5k9L1mtii3IAzu1UwxQ54bUqBH+q89DIGeBdhO7ceXMg0Pqna83MICJU7jv4Mry4bCXcPFnkwxVidFirR/1bXHBFmrxzL4Jx6wlSbjDg3SsIouXa4Nu73e/XkXk/mACRGZ V/PtP+N+ 7WVcixHKLsOfIz0ffkpDOdqh61skgAG0ufw10/+zgHV8jpY/uuXUKhto3AbF//h63ziuZSXuHq6RDA6nDOH0NjGPHDWuLQiyggRJtUgnxRZDVw8cBhe08c44BVpTqI4v3WZSv1Cg0YWNTDIU= 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 Mon, Jan 08, 2024 at 12:15:05PM -0800, Sukadev Bhattiprolu wrote: > > On 1/5/2024 4:05 PM, Roman Gushchin wrote: > > I'm not sure there is a "one size fits all" solution here. > agree - that's why we are thinking a configurable cma utilization would be > useful. > > 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 > Could you please elaborate on this - how would we use the per-cma flags > when allocating pages? I mean potentially we can add some per-cma area configuration options which will define the "priority" of using the memory from this cma area. > > 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. > > Stepping back, we are trying to solve for a situation where system: >         - has lot of movable allocs in zone normal >         - has lot of idle memory in CMA region >         - but is low on memory for unmovable allocs, leading to oom-kills > > On devices where cma region is mostly idle, allocating movable pages from > the cma region would have lesser overhead? It's not that easy: imagine booting up a small system with a cma area reserved for some hardware-related operations. This is pretty much what cma was initially designed. How to not fill the cma area up with the page cache? Thanks!