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 09C32C38142 for ; Wed, 1 Feb 2023 04:06:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CB896B0071; Tue, 31 Jan 2023 23:06:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 47C276B0072; Tue, 31 Jan 2023 23:06:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3434E6B0074; Tue, 31 Jan 2023 23:06:46 -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 2344E6B0071 for ; Tue, 31 Jan 2023 23:06:46 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id DC3AC1C33F8 for ; Wed, 1 Feb 2023 04:06:45 +0000 (UTC) X-FDA: 80417386770.02.0E0F679 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by imf01.hostedemail.com (Postfix) with ESMTP id AB0534000B for ; Wed, 1 Feb 2023 04:06:43 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=MIXk41ji; spf=pass (imf01.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=1675224403; 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=jeG1kJgmiYXAQEdKnh8AQsfZmwuryvrkVGa5eVwhPlU=; b=dPqHlNpUFmRFnMqRCYtwFeBQN5L9ziBA46VHkTqZ8+JhkY5vH2x1/AnvKZB1hRTIh4pGwk UCi8LbSHWWy7TtiHWS4IwmchGnunbX2zXCvwDAEbySPYFrBKNspbJjTNTLNeWd8/Dl9oaM I6NOHZwKu4gz3sq/h08T4vb3XG1NgCE= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=quicinc.com header.s=qcppdkim1 header.b=MIXk41ji; spf=pass (imf01.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=1675224403; a=rsa-sha256; cv=none; b=pMNY8Ufc2AASZ27/qVW2UYjOb0SiqWHGgVnQZVdjJdJ2YpFQeP0+RT6cy9M/tFGiTSZxeo mrXeMR58AxMXXKrOFaRixjFNoN839G0G617I0Sa5sFLwPWIw6jHuSqkrWolmt/ZYwsK+Vv Ext+dZNLhF8yll0tvAMcRx8Z5xqNJNA= 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 3113rD7q024180; Wed, 1 Feb 2023 04:06:37 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=jeG1kJgmiYXAQEdKnh8AQsfZmwuryvrkVGa5eVwhPlU=; b=MIXk41jil1BwBuPoa2u0uUhnCwKSypZW/r3l5Hf57KWFsqk088ItUGug8KVnqKRDYElK bVycONdBwnQ2owUL+idzjwUPzTDwg0qF3gRa0j48Pq/ex1lxsVZmLa36qZ75+L7cI2yW gYqRkpudFm4dQN4iJ3HLwMeYAcem2DfE2COah/PEg9EH5iaAvOmpSkN36Ak7HUB859ud br5BTniSAh+7P9AHNPHZB+ZKhVpYadJBvOs6zYMXqamHasBLv7J2FmDp6APIFzrnzW2T Qvngqcom8FQdRxYC99vPZh5VhvRo4v5EssJ1LNf9092iD5CBqoTsMyx7lZC7/Dxep5vg vw== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3new3uawqx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Feb 2023 04:06:37 +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 31146adg021519 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Feb 2023 04:06:36 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; Tue, 31 Jan 2023 20:06:35 -0800 Date: Tue, 31 Jan 2023 20:06:28 -0800 From: Chris Goldsworthy To: Roman Gushchin CC: Sukadev Bhattiprolu , Andrew Morton , Rik van Riel , Roman Gushchin , Vlastimil Babka , Joonsoo Kim , Minchan Kim , Chris Goldsworthy , Georgi Djakov , , Subject: Re: [PATCH] mm,page_alloc,cma: configurable CMA utilization Message-ID: <20230201040628.GA3767@hu-cgoldswo-sd.qualcomm.com> References: <20230131071052.GB19285@hu-sbhattip-lv.qualcomm.com> <20230131201001.GA8585@hu-sbhattip-lv.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-GUID: 4NYaRv6g8HHNJPyqaLQusuG72RlX1VbC X-Proofpoint-ORIG-GUID: 4NYaRv6g8HHNJPyqaLQusuG72RlX1VbC 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-01-31_08,2023-01-31_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 phishscore=0 clxscore=1011 suspectscore=0 mlxscore=0 mlxlogscore=999 impostorscore=0 adultscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302010033 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AB0534000B X-Rspam-User: X-Stat-Signature: k431nff5esofjcjapij5faoxhmz54m41 X-HE-Tag: 1675224403-33660 X-HE-Meta: U2FsdGVkX1+8fGJAtdttOmHcXToNeY8oLL5zDfNW2WYpkpLOunYz4R+8dfPZO04uhSFY5svoYaGN31LR02tE+2YalXf+ivj2zhPoHKiiIwRP2UMyLTvaTil0LeGpj8Yp11V/oYI8S2lP8p9g5Ct9Cry3PDVjkjHf/Ob7cqJXqPXF2DlLBkK8NBF20FMG926ba+61zWITzNc5qpDGoNhm4LGOtrERbcmEyhMbM5uhd494mXdGdhXqfm0WrTZ7JdBisnSmZG5yFxPXvH4pGEv8mBMNldmoev082VEGxveR0YFOcB/9u+wdoKP27k5TaHjEL6WbCIJgk3gE8iNJCUhYs1swPJx/EZ2ZaUx/fgnmMSo9Kf5yXI84Xc0gcMFeSWDrrVJipHhcsvLO0Xezk09qvK6I3Nc/2uZbnbCcSzXKqfzjrz1utC/Ff2Lz/b6I9ltHNqJhlot6+5SY17yOXzY1fiVAAdq1uTvT04UC8FUi5KH5QZhhbgQeURtw9wJDF5IE6mC/CYetPgS7tWGHRCoXLFHac8sMomY7dUhxgqCWo35kTrporXIlsFmWPmrZ/Rz60xd4DQiA+DeonDE8aFrbNeLr0jSwi6Mnkdbhpav+i0gM7z0IdccqR6gDdXaKw/5hdI3YaXqyHpl5a67vFXOJPZDXbBJmZsZ7Ugh7CGTOwmMVEkxF7yIi48u/CYv1WFELz7RGwi7tjO1rtR2dLbBEtUigmC5bz+7+EL71Nbw6KCaSLAjq6gixxyh8lVN4zgHiYXfyY0VOhNFXVH4ttpjTvnqvs+WKSR0kH1IT3y+sKSVIRROLFb3PTdu8zftuixpJU16Rs7SbaiUZNMUtGDaUKoQwfnpDW7t6svUrwJ8TcCWRDcoIdpRBjfN+ZnZo5gPghLCjPPeXTGovh8pnCUxsiL9QxOb3661SwE+Gqj+SIwGS5OQyzTObGJeKT1hm8nYI3/Z2zYUd9thBv84pDBU 0p9Dd7Lg aS50qsqr0rm6MjFOMjF2U7FgTR9rgLjPXTwd4hcPeq1HTeBhploJCa1hNjH/b80u2ot4s9T/BReI8z+IOSdW7lyIDk3jN2vYnWD3g1Em3CgVT2utVRLDOng+eMpcnNcW1jcWOtNHs4eTWGu19z26efm44et4PEYY0sFxx7vcw0txuw3fnsAn1zVTUqtcfJYErvZeyYBypppfUwXh8nIWyeD5fSNbwaoWPkjTRHrl2LLklEPA= 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 Tue, Jan 31, 2023 at 03:59:36PM -0800, Roman Gushchin wrote: > On Tue, Jan 31, 2023 at 12:10:01PM -0800, Sukadev Bhattiprolu wrote: > > On Tue, Jan 31, 2023 at 10:10:40AM -0800, Roman Gushchin wrote: > > > Hi Sukadev! > > > > > > Can you, please, share a bit more details about your setup? E.g. what is > > > the zone size, the cma area size and the value you want to set your sysctl to? > > > > Hi Roman, > > > > I currently have a device with 8GB Zone normal and 600MB of CMA. We have a > > slightly different implementation and use up all the available CMA region. > > i.e. going forward, we intend to set the ratio to 100 or even higher. Hi Roman, > It means you want allocations be always served from a cma region first? Exactly. > What's the point of it? 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. > The idea behind the current formula is to keep cma regions free if there is > a plenty of other free memory, otherwise treat it on par with other memory. With the current approach, if we have a large amount of movable memory allocated that has not gone into the CMA regions yet, and a DMA use case starts that causes the above condition to be met, we would head towards OOM conditions when we otherwise could have delayed this with this change. Note that since we're working on Android, there is a daemon built on top of PSI called LMKD that will start killing things under memory pressure (before an OOM is actually reached) in order to free up memory. This patch should then reduce kills accordingly for a better user experience by keeping a larger set of background apps alive. When a CMA allocation does occur and pages get migrated out, there is a similar reduction in headroom (you probably already know this and know of the FB equivalent made by Johannes Weiner). Thanks, Chris.