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 76C08CD68E0 for ; Tue, 10 Oct 2023 00:14:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E38DE8D00A4; Mon, 9 Oct 2023 20:14:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC16D8D0089; Mon, 9 Oct 2023 20:14:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAFA78D00A4; Mon, 9 Oct 2023 20:14:40 -0400 (EDT) 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 BEB8E8D0089 for ; Mon, 9 Oct 2023 20:14:40 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 91AAF4046C for ; Tue, 10 Oct 2023 00:14:40 +0000 (UTC) X-FDA: 81327630720.18.0F14791 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf17.hostedemail.com (Postfix) with ESMTP id B06DF40014 for ; Tue, 10 Oct 2023 00:14:37 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kwVhcizA; dmarc=none; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696896877; 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=72Q2u7uyEpMo4qn4YZrkB/a8oEVm5Ir2x88QUCLrpoE=; b=wuNYRQpv6CcQgZtMHn5oz+CVRoFdvEgdC6DcE3wQ5LBIQ9qc5lv5s1Sh3eQhDlTBjU2Rf/ QLRKjiXRNLR+s3LP3mUDsGcqv6Sm/Fc1cL/omvuNUkd4WD6DO9Rgy6ug3OEPOAzUYaHS59 DSd1h0GCi4XW4bmob0xccj1Kh4+Ml7U= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kwVhcizA; dmarc=none; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696896877; a=rsa-sha256; cv=none; b=BVt9Jtgy6SR6ms432ifMZGVZ7JaTGbYfpAU+DR2MrdeEPGPZqxWwR1zRZVbksqrPX0TC/5 dAw6NV8SitbEpkvmPidweZIsWvavQY10aRgbwGYG0NUTXBnySUpYB4hMBuZOgqtEJKVIVJ myuRymYpL2tGvrdEszmXcFlhI/9bxOI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 509A5B818A7; Tue, 10 Oct 2023 00:14:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AE39C433C8; Tue, 10 Oct 2023 00:14:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1696896875; bh=zQK6y7u6qjXeMUWj/O9jsTYxx+DpeLYJg5CFzqy8x0o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kwVhcizAsN80h0tCt2iFYIUN7yrErpynGIp1vjSejGl9TmwbhGgAINMH6t+xazN2D lEZTBL7xALnNa86mD3nica8e30tilKKsk0MWRVKM0UkxDVMPFeoJTHMD5kZO/ivbl/ 6chrKYnyZvzMQAZAb3IPmigGqjtSPW8raNPQNwGs= Date: Mon, 9 Oct 2023 17:14:15 -0700 From: Andrew Morton To: Zhaoyang Huang Cc: "zhaoyang.huang" , Roman Gushchin , Minchan Kim , Roman Gushchin , Joonsoo Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, ke.wang@unisoc.com Subject: Re: [PATCHv5] mm: optimization on page allocation when CMA enabled Message-Id: <20231009171415.cfc26b45c2f9f4489afe16c2@linux-foundation.org> In-Reply-To: References: <1683782550-25799-1-git-send-email-zhaoyang.huang@unisoc.com> <20231006141750.5423083520f74bc0746fd249@linux-foundation.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B06DF40014 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 3gxoxnzz5ajqcijpnyedomb1g1e7r1ix X-HE-Tag: 1696896877-521889 X-HE-Meta: U2FsdGVkX1+tNBK9hqE9cbUX/69f6qqD5KGUbgnsbpyDnD7hS6YMoUQg0tWhIo2buSq8Ucy/HfSlrXG2VRDyTzaMTDRMZicKnheiIUcc4FTVvupH+0k9743aoMQAXlyzlv1odWRiP6bKZ6QjpUxPB3vM39JwNbpsBA+uNYeSU23K++NqMRsumHHX3zOc++X5d0Kk7FSeDOfspXWSqZUokqrWs6OxWdo9V+hFzYlOK72WP0TyppcdFgoVtrV6lf+t3ngaFbuPKELN89+akwX0YD8ax0OyWs7n+NL7iIuvMG36/mrUzz3vuTj+4ki3wZ74tIQ49GYzUF54wuSP7UeQNkleUoomcEj6tvwoPASdy5qL+UGusuW/FLROe3Xsjh/FbfdO7DGWMwo1e9zF/4XShRxzbP189t3ola3e4feYFyQNkZDTuMg484ZZHvV+9ScN64fsvOmXKZVfdDisdF5gcoIZeHlYkJBBHTPqJgfWu3rEdCJcv1I8mgNH/gVEG5Xv5dwOuFx0otyE71TYQtVazo45U2RKnvL2oe2Js3g5NYnTs8FndAdbIhcGpGrPlY5EK8dZ9qtXskckol6+mtBAw0wbIpVLcU9Fu2PV3eOh4Umc/Goo0y8AxMFIyjk0yEu1W3VrUWg58jYqMKpL3zyTIr7igoSb2d62F3Sbb4xwIUuhVE010+dxoCiJ48z/xHautuMtUkQOOBZynrQfM4TAEq7FKN4w5mKZ/6Wlum0NeEZj1qka5hYAjMPatm7mQ6h7rzjXOqGknWNg41RWtHEShd6ahCX1k6ZNJKsUuTSGH39Yedg+VQoPXnGBA69iJB+4q3kXR/+rQNonqeSA3f+LbZTvhUanX1JZX238+Du6YeF/X4UxEN8FsDNy8Wc8xEXW8XtBTb7IR2x7DgZKNU8gxpFqBclcm1e+aXPHtdDnsRRLXWkZxTBd1oHwLru2Mc1t2Jh3AvJVSANVDw9vtbh f6FknkFc LIMkkui+epTuZTckSHRkCT06uFk7+8iudOpX0tLVidVFPl3Ai+N+hbq8kzE8f6uQTEFEgO1C+LcB213RB5Oq/FIu+ZP6tw0kO8LhKpcnyDg0n/DBYIDbHhdWBBfbi417n1sWSD/IVVQCWkSs5auwAtP5XdqUbBScZ6EU5ib4qppFjnb4YjGmi71Cr4V64C5mQt4rB4HMq1qQ4Ws/b0NOYb0kLUTMsTyn9Qb1LOgcR+lD9vrL61Wf4JWmB1frJgHRsXzHK 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 Sun, 8 Oct 2023 15:54:40 +0800 Zhaoyang Huang wrote: > > Roman previously asked > > > > : Also I'm a bit concerned about potential performance implications. > > : Would be great to provide some benchmarks or some data. Probably it's > > : ok because of we have pcp caches on top, but I'm not 100% sure. > > > > Are you able to perform such testing and tell us the result? > I have applied this patch in a v5.4 based ANDROID system and got no > regression problem. Actually, this commit is aimed to have > alloc_pages(GFP_USER) use CMA instead of stealing U&R(could lead to > GFP_KERNEL fail) only when zone's free pages and free cma are around > WATERMARK_LOW/MIN which would NOT affect most scenarios. OK, thanks. Could the appropriate people please take a look at this? It has been in mm-unstable since May. Thanks.