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 C46BAC3DA6E for ; Mon, 8 Jan 2024 20:15:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05E0D6B0074; Mon, 8 Jan 2024 15:15:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 00E6F6B007B; Mon, 8 Jan 2024 15:15:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E18B68D0002; Mon, 8 Jan 2024 15:15:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D2D626B0074 for ; Mon, 8 Jan 2024 15:15:15 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id AA2C140882 for ; Mon, 8 Jan 2024 20:15:15 +0000 (UTC) X-FDA: 81657248190.16.275A182 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf05.hostedemail.com (Postfix) with ESMTP id 4DBFF100019 for ; Mon, 8 Jan 2024 20:15:13 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b="LK hezgA"; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf05.hostedemail.com: domain of quic_sukadev@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_sukadev@quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704744913; 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=bOUKNttGfktqe7VE8ZoTU5OPnxZCVqzq7LfDcVymoE8=; b=0Bvpbo+g0ig0Z1SVWWaU2SNg4o38LVN99TgsEqfk39AsDFhlsSn4VaOcMwKe3J/HfHThPo w3EZqi2hqSyCONFa9eIoYtoUUP2rFA87jN5e882LsYmDNK3RaXbshjvQOn0XlhcwBzF18h kQA4o69+A9NqcUOv+1MV4NlKk0h29Ow= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b="LK hezgA"; dmarc=pass (policy=none) header.from=quicinc.com; spf=pass (imf05.hostedemail.com: domain of quic_sukadev@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_sukadev@quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704744913; a=rsa-sha256; cv=none; b=kfxCmvP8HiFynwzoa3aFv8GzvANuS03iS8k8b81lLAY/MSQdpEjcDh9SVateZKRcUWrihX BVKmrdD/eJedlSb4PfPz0/1p7McTSFT8XFDiUSzXUO77tT5CZ56Dh8VJAu9pQi6PGdzGgr RXovuCqJ3ZLt+hALx/aWjJw0Y5PY+pI= Received: from pps.filterd (m0279869.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 408KCVga003096; Mon, 8 Jan 2024 20:15:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s= qcppdkim1; bh=bOUKNttGfktqe7VE8ZoTU5OPnxZCVqzq7LfDcVymoE8=; b=LK hezgAjvBK7rWq12it0R3vj7GnsfzgVRI+PMwKa9QUmrpfTKio9114BT89Vh2/3nf GQaI135oiUlBTKkl0r8WbYhxGHAsWYX+XeDPjF+dKmmY6RN6qAbEzuPjOPwM4WG1 6A8GqvFVKGRf9z5dAKylmle6g2rHOMj996Yxi+P47ahhIG3KX6/la58zGn3BIc9K Aj00y2kdasqsfjhwoLOrIzuWAeqh6HtrjTDC33tlcNBXETi7I8xDjw7uqVBVKqua rz+7R4eWRfoQqt3AExnSAQHm6FvbbeDHhko8gdixwbbbVhe1VJbOK3sxRg/DSB6u IlhRcL97W7i5QE070Nig== Received: from nasanppmta01.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3vgq2yr3x3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Jan 2024 20:15:08 +0000 (GMT) Received: from nasanex01c.na.qualcomm.com (nasanex01c.na.qualcomm.com [10.45.79.139]) by NASANPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 408KF7xE010645 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Jan 2024 20:15:07 GMT Received: from [10.110.48.152] (10.80.80.8) by nasanex01c.na.qualcomm.com (10.45.79.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Mon, 8 Jan 2024 12:15:06 -0800 Message-ID: Date: Mon, 8 Jan 2024 12:15:05 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] mm,page_alloc,cma: configurable CMA utilization Content-Language: en-US To: Roman Gushchin CC: Minchan Kim , Chris Goldsworthy , Andrew Morton , "Rik van Riel" , Roman Gushchin , Vlastimil Babka , Joonsoo Kim , Georgi Djakov , , References: <20230131071052.GB19285@hu-sbhattip-lv.qualcomm.com> <20230131201001.GA8585@hu-sbhattip-lv.qualcomm.com> <20230201040628.GA3767@hu-cgoldswo-sd.qualcomm.com> From: Sukadev Bhattiprolu In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01c.na.qualcomm.com (10.45.79.139) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: QpD1E0sTmcBht6Zd9wSEJMF_DFTKWM_j X-Proofpoint-ORIG-GUID: QpD1E0sTmcBht6Zd9wSEJMF_DFTKWM_j X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-09_02,2023-12-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 bulkscore=0 malwarescore=0 mlxlogscore=793 clxscore=1015 priorityscore=1501 phishscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2311290000 definitions=main-2401080167 X-Rspamd-Queue-Id: 4DBFF100019 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: o7ghe8yg95t4kpn9my67jgwiie73oecu X-HE-Tag: 1704744913-275676 X-HE-Meta: U2FsdGVkX1/X9opGkHowcszoMT5cX6yLbTpTmxeKfGYQcC00KTtwupnhqq+RsHnNRv/o8bh6UwOLKyui19xsEOWALgfZ5ryKm1LgJs6RuzFR5CfNAe36Gipjt2LzyYmjlJUzqO3eB6s3yiQ7egIubQS22Ph6FGEKj5KxhdZCJ+SBaj/mJtGT18KMPUswNJFVum19Cku9hnxziDwDK8xn/uwg6lc9+XZoyWDhNIFuVVtRmGbpjiufImi6546nqBVla+ecMA5+aKiEAsDu6/eKpZ3C6qLAtiNaHRWL6SsYxOxSkRUpxXk82kcwtqJ5pdBOWA0Sha+HvfQHDqYY+V3zhIe1ZsXsnsAVAm27bVl1kPsJzqCFQBPyqz/IbHf5KgWKFqcKLaW7OpdYh+0J1k1p9fVdaXvqzv8XinK6reUARLwVR83ooAbgVE4ia3lVJ7vLtfGz2FN/oFAs3l7iwRWcHOcRXerW+HxNkh7XeLz+P9SGxB+QlSpSrF+Q5Xw4FS/eizLN8uAGxITdSvcjO8VxJZxiT6ojXIRsMy/UEHd39FIWXGnCMn43Pg04x+Xt4QVaHjvF09aNK9TqcoIH1LD3bUIm+5gJHMsQimNCZwLrInS4CQ+LHcJM3QuSxCKm0y7o9uW4LaQtwUpY1TTIc80i10/t5Ar4MbiS/CQgBnAclmmxAhvV0u26p5j6YwS1uPXKxsvjmbDTU54yjFtw9ZsXrPGD6cE4vrRMeizJcoa3WJFrHu2K/4wkyjIfd1jQbZ/Eyg9tczZcA+MN13eAIJ1y1MHdRLpeU/y5tk8ark7W9Sh7yzOqHH2vMX7zcmGZQBqS1vv66fimw/x5OaVGVZ9Z1oYV0W10AQeWxe+XGZnyb4k4xe86hiMG/aFHkfMRjeiHDb4FNKzPkdPgFXk4w/puHceBOCQlzESk9/KRwvgVUIs4U9ROBb2J7WO+v7PW34LS5f9f1zTzpJqjHJUfYH7 3iYNuAWX 4nPtfiMl6niUoZFE6UhFACXd9PL/lwQeIcw5hvrmgjFEpw5rDd38rF8ZO/SlK21iwnjSqGLgIp/vkjoxbcme0fb323YyFMSJQPZ9yrWDHh6jQhO10jNOxWSbmlrOXmSc69dtohjnfJiP5Sjq5LAaDk6V+NzQt9Su8Igqb/UOnpd3zgRUm72i00QHD5BTSii+ZeEuDuD/+UD8qIBtPOil2l+RrCg3rLvtr6y6+BgpDo/NHTBwkWW6NgBsQN3xBBpJNOJZ3QhMt3+ZU/tHZbyMFPT2NEnYkeiPVpPHP 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 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? > 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? IIUC, this redesign for smarter migration would be in addition to or in parallel to the CMA utilization right? Thanks, Sukadev > > Thanks!