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 5F6D9C7EE21 for ; Thu, 4 May 2023 06:30:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 802AE6B007B; Thu, 4 May 2023 02:30:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B1966B007D; Thu, 4 May 2023 02:30:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A0B76B007E; Thu, 4 May 2023 02:30:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by kanga.kvack.org (Postfix) with ESMTP id 013F46B007B for ; Thu, 4 May 2023 02:30:46 -0400 (EDT) Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-4f14468ef54so107858e87.0 for ; Wed, 03 May 2023 23:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683181845; x=1685773845; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mAlD2OvupOW/l/Os47QmkRUegAgHbuOOHoWZYkWzIMc=; b=N7UZs0wuVmHxu1Q4YnamprrYg93GRxgo97go6IrlPY4A7EJB6yXy7eTqE5Ff4GZG8S O0Dqbv61pVm3fqJoI9MRGeER7JYsIE468jkcb/sXCyg0uVL+0g0Z27AeZHtce4tDjE3A lvXuJZolyFGvdmAGBP3uqB0ltqY5EQ7s6MUW6M9gEtbDc1JMuy9PJvOlcBIpYRBLoF/o lN3oaLRlgs2zW6+pjUNuTjIz5muddjpaA4ZT4zZg9TK+R6ivfbQbGBzQhq1FNgLFRCnU Dk3ac9ds27twDS84Mwef+TnBuKJSkLC6lzI4D0jQ5POIBVoML/RGKpnW1qL7mpWiXEnE aDiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683181845; x=1685773845; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mAlD2OvupOW/l/Os47QmkRUegAgHbuOOHoWZYkWzIMc=; b=DVZEn3a8N1HHUx1NKJOOOX7OPFK0oPL5Va3NKwGziqUsz3QENO04f5PEIq0Zjba+QW QzE+ZAx9DM2ZFeStwVRqLH1+8LQ/LmAXQZuQP0ZQ6kB+QUR7vio2/bEEvPuBT3S9C/zR ZzwyTNxKQ21OVwbxv86IdkdQnEeICOCWhMS7BkjYJ2HkEFM00CiuGsf+hfgSiJjBFZBf M2D6zG4fHHOefzNOTXvzGv6M718m85Wm3o9Z8ugc6K3BAoIrXPC1BGb3ubaHYGN+itHW KVdft1b1EJ0cY/TOzgO+huPehz0KAkEWkN4MhNlRuK+QfYtLG+rVocjk1DmKmQQgDDME sz5A== X-Gm-Message-State: AC+VfDwKU3BGuWHiGSo9KZwhn+hhDCGVAqHzT8vY2fGTDlatMljErLih ytGznqlHdDmquOTNmxtg04HmFTK1d3/3hBQt010= X-Google-Smtp-Source: ACHHUZ5KwSJm1M0hRlQfDk5XlOt8nfKErevpCp8qwFi2fGpxmW6qG2PSVayuL0KMNL3RErrE2YLDc5UVPjlfi/j21KM= X-Received: by 2002:ac2:5d23:0:b0:4f1:4602:fb63 with SMTP id i3-20020ac25d23000000b004f14602fb63mr13846lfb.41.1683181845140; Wed, 03 May 2023 23:30:45 -0700 (PDT) MIME-Version: 1.0 References: <1682679641-13652-1-git-send-email-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Thu, 4 May 2023 14:30:22 +0800 Message-ID: Subject: =?UTF-8?Q?Re=3A_=E7=AD=94=E5=A4=8D=3A_=5BPATCH=5D_mm=3A_optimization_on_page_allocat?= =?UTF-8?Q?ion_when_CMA_enabled?= To: Roman Gushchin Cc: =?UTF-8?B?6buE5pyd6ZizIChaaGFveWFuZyBIdWFuZyk=?= , Andrew Morton , Roman Gushchin , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , =?UTF-8?B?546L56eRIChLZSBXYW5nKQ==?= , "fangzheng.zhang@unisoc.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Thu, May 4, 2023 at 2:23=E2=80=AFPM Zhaoyang Huang wrote: > > On Thu, May 4, 2023 at 12:30=E2=80=AFAM Roman Gushchin wrote: > > > > On Wed, May 03, 2023 at 03:58:21PM +0800, Zhaoyang Huang wrote: > > > On Wed, May 3, 2023 at 6:01=E2=80=AFAM Roman Gushchin wrote: > > > > > > > > On Tue, May 02, 2023 at 12:12:28PM +0000, =E9=BB=84=E6=9C=9D=E9=98= =B3 (Zhaoyang Huang) wrote: > > > > > > Hi Zhaoyang! > > > > > > > > > > > > On Fri, Apr 28, 2023 at 07:00:41PM +0800, zhaoyang.huang wrote: > > > > > > > From: Zhaoyang Huang > > > > > > > > > > > > > > Please be notice bellowing typical scenario that commit 16867= 6649 > > > > > > > introduce, that is, 12MB free cma pages 'help' GFP_MOVABLE to= keep > > > > > > > draining/fragmenting U&R page blocks until they shrink to 12M= B without > > > > > > > enter slowpath which against current reclaiming policy. This = commit change > > > > > > the criteria from hard coded '1/2' > > > > > > > to watermark check which leave U&R free pages stay around WMA= RK_LOW > > > > > > > when being fallback. > > > > > > > > > > > > Can you, please, explain the problem you're solving in more det= ails? > > > > > I am trying to solve a OOM problem caused by slab allocation fail= as all free pages are MIGRATE_CMA by applying 168676649, which could help = to reduce the fault ration from 12/20 to 2/20. I noticed it introduce the p= henomenon which I describe above. > > > > > > > > > > > > If I understand your code correctly, you're effectively reducin= g the use of cma > > > > > > areas for movable allocations. Why it's good? > > > > > Not exactly. In fact, this commit lead to the use of cma early th= an it is now, which could help to protect U&R be 'stolen' by GFP_MOVABLE. I= magine this scenario, 30MB total free pages composed of 10MB CMA and 20MB U= &R, while zone's watermark low is 25MB. An GFP_MOVABLE allocation can keep = stealing U&R pages(don't meet 1/2 criteria) without enter slowpath(zone_wat= ermark_ok(WMARK_LOW) is true) until they shrink to 15MB. In my opinion, it = makes more sense to have CMA take its duty to help movable allocation when = U&R lower to certain zone's watermark instead of when their size become sma= ller than CMA. > > > > > > Also, this is a hot path, please, make sure you're not adding m= uch overhead. > > > > > I would like to take more thought. > > > > > > > > Got it, thank you for the explanation! > > > > > > > > How about the following approach (completely untested)? > > > > > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > > > index 6da423ec356f..4b50f497c09d 100644 > > > > --- a/mm/page_alloc.c > > > > +++ b/mm/page_alloc.c > > > > @@ -2279,12 +2279,13 @@ __rmqueue(struct zone *zone, unsigned int o= rder, int migratetype, > > > > if (IS_ENABLED(CONFIG_CMA)) { > > > > /* > > > > * Balance movable allocations between regular and = CMA areas by > > > > - * allocating from CMA when over half of the zone's= free memory > > > > - * is in the CMA area. > > > > + * allocating from CMA when over half of the zone's= easily > > > > + * available free memory is in the CMA area. > > > > */ > > > > if (alloc_flags & ALLOC_CMA && > > > > zone_page_state(zone, NR_FREE_CMA_PAGES) > > > > > - zone_page_state(zone, NR_FREE_PAGES) / 2) { > > > > + (zone_page_state(zone, NR_FREE_PAGES) - > > > > + zone->_watermark[WMARK_LOW]) / 2) { > > > IMO, we should focus on non-cma area which trigger use of cma when > > > they are lower than corresponding watermark(there is still > > > WMARK_MIN/HIGH to deal with within slowpath) > > > > page =3D __rmqueue_cma_fallback(zone, order= ); > > > > if (page) > > > > return page; > > > > > > > > Basically the idea is to keep free space equally split between cma = and non-cma areas. > > > > Will it work for you? > > > I don't think it makes sense to 'equally split' cma and non-cma areas > > > over free space while cma could occupy various proportions in a singl= e > > > zone. This fixed 1/2 could lead to different situation on 20% or 50% > > > cma occupation. > > > > Can you then, please, explain in details what you're proposing instead > > and why it's better (not only in your case, but generally as well)? > > For the context, my original usecase was cma size under 10G and > > the total memory size between 32G and 128G. > > Let us look at the series of scenarios below with > WMARK_LOW=3D25MB,WMARK_MIN=3D5MB(managed pages 1.9GB). We can know that > 1. optimized 1/2 method start to use CMA since D which actually has > caused U&R lower than WMARK_LOW (this could be deemed as against > current memory policy, that is, U&R should either keeping stay around > WATERMARK_LOW or enter slowpath to do reclaiming) > 2. it keep using CMA as long as free pages keep shrinking (this is > against the original desire of balance cma & none-cma area) > > free_cma/free_pages(MB) A(12/30) B(10/25) C(8/25) > D(8/20) E(8/16) F(5/12) F(5/10) G(4/8) > optimized 1/2 N N > N Y Y Y > Y Y > !zone_watermark_ok Y Y > Y N N N Y > Y sorry for the broken graph format of previous reply, repost it here.N stands for not use CMA while Y stands for using free_cma/free_pages(MB) A(12/30) B(10/25) C(8/25) optimized 1/2 N N N !zone_watermark_ok Y Y = Y D(8/20) E(8/16) F(5/12) F(5/10) G(4/8) Y Y Y Y Y N N N Y Y > > > > Looking at your original patch, I see that __if_use_cma_first() always = returns > > false if zone_watermark_ok() returns true. It worries me. > ok. we could deal with the scenario here when free pages is higher > than WMARK_HIGH > > > > Thanks!