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 CE2C8C05027 for ; Mon, 6 Feb 2023 05:22:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6348F6B0072; Mon, 6 Feb 2023 00:22:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5E50C6B0073; Mon, 6 Feb 2023 00:22:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4AC2E6B0074; Mon, 6 Feb 2023 00:22:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 37A496B0072 for ; Mon, 6 Feb 2023 00:22:39 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D5A0BC0A7E for ; Mon, 6 Feb 2023 05:22:38 +0000 (UTC) X-FDA: 80435721996.17.FD2DC6D Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf26.hostedemail.com (Postfix) with ESMTP id A0858140007 for ; Mon, 6 Feb 2023 05:22:35 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=aHStcY5w; spf=pass (imf26.hostedemail.com: domain of quic_cgoldswo@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_cgoldswo@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675660955; 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=p+rsc6DQbrD7yDxjGjkUdxSj3SZhUyq9RJ28wdQbzLs=; b=qhAFRFtxnCPkEb3F0AHdJGghAopkCs9ohhKbb7fUPTOFtlzSSRtMyjA9gcJbeXDj7mMmNP IfABm8DBHO1U2jxAiqtkN2SK5YdJVqS5mZ2TkZTnyMCFcQLFPFeP1W/evk7e1Uy/25SdYE Z9mi2QqCF/V5q0/UIKru2EJlBSXKSts= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=aHStcY5w; spf=pass (imf26.hostedemail.com: domain of quic_cgoldswo@quicinc.com designates 205.220.180.131 as permitted sender) smtp.mailfrom=quic_cgoldswo@quicinc.com; dmarc=pass (policy=none) header.from=quicinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675660955; a=rsa-sha256; cv=none; b=KKQ0z10l2HSm0cbCB3GX9UCbtVmN+rHdQCQ3Hi2qhko4bbrAKYtDSrnc01I5C74xHhYomA GZMC5q3eUgv1iEoSJC091P890WLWnph8zYQN2GxEdk5GhRpftoPpTiWmU8gNQ3jUX4uZh4 Va4QCEFNiZbQVDFm3vw2/N0FCLoF4pE= Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3163VnAD029567; Mon, 6 Feb 2023 05:22:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=qcppdkim1; bh=p+rsc6DQbrD7yDxjGjkUdxSj3SZhUyq9RJ28wdQbzLs=; b=aHStcY5wTECufCF4kwixUeXpxWkQeC4NSP625nZLB60crK4f73wjIkDvBzVqZFQokqdt HCumH7aLwJK8XH28gl+pNzo27sRKFRstXVEjd2wSMHMtsgb+PLZGwP/9ygIcawAnIpIt +Gpz85BI2REHVb+aY+9HyfRalmXvvumJ5x5dv6Xroy4K/TFzeJSjqVSe8MeQiEeHugut 6lGhnJwc02ou8oA3aQhJr6/4XsyCAoeUfFOpvBL5Aihe+fxyGi5MvDJJ2qFQdLf0Kp+x EFcDWA/5LhEM8+XWaxzyJjK8HMjZk4nKkcr2kI/mLUMV/n/Qor9vCkOABxc3AiUQpQnj Sg== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3nhey72uv9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 06 Feb 2023 05:22:31 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 3165MUwt007488 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Feb 2023 05:22:30 GMT Received: from hu-cgoldswo-sd.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Sun, 5 Feb 2023 21:22:29 -0800 Date: Sun, 5 Feb 2023 21:22:28 -0800 From: Chris Goldsworthy To: Minchan Kim CC: Chris Goldsworthy , Roman Gushchin , Sukadev Bhattiprolu , Andrew Morton , Rik van Riel , Roman Gushchin , Vlastimil Babka , Joonsoo Kim , Georgi Djakov , , Subject: Re: [PATCH] mm,page_alloc,cma: configurable CMA utilization Message-ID: <20230206052139.GA21897@hu-cgoldswo-sd.qualcomm.com> 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: User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: Qc1Sgx4fNAH7_Ob2BY89PfaraWLKIhm5 X-Proofpoint-GUID: Qc1Sgx4fNAH7_Ob2BY89PfaraWLKIhm5 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-02-06_02,2023-02-03_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 mlxlogscore=738 priorityscore=1501 adultscore=0 suspectscore=0 mlxscore=0 malwarescore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302060046 X-Stat-Signature: ukpxzb71ozb3deke4rxfp415ocwkjhk6 X-Rspam-User: X-Rspamd-Queue-Id: A0858140007 X-Rspamd-Server: rspam06 X-HE-Tag: 1675660955-189859 X-HE-Meta: U2FsdGVkX1+VzzCffCrLcmC8BpJMMXwXP+bBmbScy4EQNT+23GNcNCV/07wycWjDf/XRJdnieIWDY4mBwIWQ1Y4BIyu6VrXiuqxYBtfpwjEHJmYr/jBxsSNYCXvfAJJCMyk4PGYou1Bdu9Lx9mYtjkBN+i1mP2WKOhFEH6cC6utdEcW28odcm10Eu8WoavZ2kftF3HZDJX//bbN50q7sQzwP/93oxKyTmA+dWTYVFWekNn/RTJ/MFgEDIAYQK+8DhJwywghdeZ0yeBuNAVPt3kzp16dWIBd1HqvcLMfuCr+5i7DtfdNfRxD+8vEIKlzc10gK3bdWrphpFHhWMzXCNyUsgGpkJXyxwMlHXo8oTahFs8iC7XYdP3d3zdIgO8DRIu7w3s9CtnCLX3gA9z5gb5VFd0zj8DmOaXjSUKA2CbTAD6+3MMno8XY8OtUEUX+mRePL4FPtvCxgM7zRM+AMxmJb5um7AiTo5o1Q9OeOQk6mMoxccIKuf6DDZt2LT9MAIAEAqzo+5v3BWHdsr31mN1MWvgwzqV3Jc6jY6bsTHqSLg6wGqK57hlIV5w5akJFilSKG4Er8Gc025jlI9QPnKnvD9GxoCtHX4NXzWslgsMdu4nbWRKANLk9x8rCRKaYYuOw/hMJes/Lc8pmoWQ34mPNulHnKQbUrI+cqFJ1S3c95oFB1roKFieGuEe+qMjGsTFHNPSVqc24okkULxvc/aU8RXXRj5nLBc9ME8EJP3b8GP0A7EVdcqrYG5I303Gq0f9Kqq9MfFHDbfpIwFkT0NKDnILpioWCFjb+/VY24rADdCYRkRRKchvtyK7f2/RWi9LmTK0CmXV53QmBspHaCDuKk9LVnmDMdXZgC6FHLidCsGZc/V0d0U/flasArMbkxkgyVX47O0K8fqzEoXHG2uDx6zEqTRX3xk7bmXqGqxZiFSbYcMviON24k/hD7fbZPfYGg0G3w4866s+Vm3iM RO7xjkMH +jSuC40y3f5LgXnM4lFdWumkgvXVTbjGz1x0FB8t8nTMSTFwLH4fwp0AOjtlRGbB3AkBnzQmZhxJuI0X/sd9Fvvd9oaOOci1HSy88glVu1YaBfWznK+cl0FvOb1hgYwkCOnPMccHdQdconk1MmSWQShU9cDAYoDRHPALkXXoITgtxGhqRKUuOwqNhqx66CP8Q8Tvq+ggozABUJ8mGGgn13g0HFJELqrKoDiH5NxO9DIDC5KQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 01, 2023 at 03:47:58PM -0800, Minchan Kim wrote: > Hi Chris, > > On Tue, Jan 31, 2023 at 08:06:28PM -0800, Chris Goldsworthy wrote: > > We're operating in a resource constrained environment, and we want to maximize > > the amount of memory free / headroom for GFP_KERNEL allocations on our SoCs, > > which are especially important for DMA allocations that use an IOMMU. We need a > > large amount of CMA on our SoCs for various reasons (e.g. for devices not > > upstream of an IOMMU), but whilst that CMA memory is not in use, we want to > > route all GFP_MOVABLE allocations to the CMA regions, which will free up memory > > for GFP_KERNEL allocations. > > 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. > > I guess you considered but did you observe some problems? Hi Minchan, This is not an approach we've considered. If you have a high-level idea of the key parts of vmscan.c you'd need to touch to implement this, could you point me to them? I guess one drawback with this approach is that as soon as kswapd starts, psi_memstall_enter() is called, which can eventually lead to LMKD running in user space, which we want to minimize. One aim of what we're doing this is to delay the calling of psi_memstall_enter(). It would be beneficial though on top of our change: if someone called cma_alloc() and migrated out of the CMA regions, changing kswapd to behave like this would move things back into the CMA regions after cma_release() is called (instead of having to kill a user space process to have the CMA re-utilized upon further user space actions). Thanks, Chris.