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 3B540C77B7F for ; Wed, 3 May 2023 07:58:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A99356B007B; Wed, 3 May 2023 03:58:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A49976B007D; Wed, 3 May 2023 03:58:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95FAC6B007E; Wed, 3 May 2023 03:58:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by kanga.kvack.org (Postfix) with ESMTP id 2D82A6B007B for ; Wed, 3 May 2023 03:58:45 -0400 (EDT) Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-4efe8991bafso6138830e87.0 for ; Wed, 03 May 2023 00:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683100724; x=1685692724; 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=MDGY0xJAU8Y7HztZyvyAB9vXE6wA5gbSmqoQkXQgFnQ=; b=cRzgV70idcY5OAcFkQkiInku3fp47uJpyuCvW43e2jvEY4bWMytUpe4/XzzBnuuNhT 7UK4oHej1MljNCDtoEeAIS5I/2nNcpwiM5PcLun0Lz/XYJdp+f19I7qXVsk07N068FDm FfehpoWMrFFt3f/ZzL6XvwMRrJ0ZpjYOnEkiCWRHpeMd1AVDePGM8tv65rY/skpwNvx2 GjQimojkZRjgZ5/4NB9xrXYwG1aehpDTpY525Dncvv2fTOx6JY76OxIoc+QvzXDmwR8M EnMYXG5WjIc0xN3e5yBem1On7A4iWxgHHt6KB5IgCyzW40MSx30mBZfrYFQRnJE43VKn j0rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683100724; x=1685692724; 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=MDGY0xJAU8Y7HztZyvyAB9vXE6wA5gbSmqoQkXQgFnQ=; b=Ei49fJa6oyMzk0lToTF3tcYYdkyveSfDpEIYgtORGcL1VRYAbudVqObhCVpm/jNAnK K5tJQRxLPRe4p6hoyqleFm6WZ7nS2hdyh5ESKzY3hh66vKaSeytduynjS38pmI/xAELG W3FGsF2agmifvPk13ko4LyZGsXyUKJLNzuuDmpRGxswisbH5R4oGSBhN+dKlRthmb6e0 HSEYUa+lcCptrPIOt8Zr3JBQ+kM9qS8qRvLSdNGwlNAK9kUHIPYa8k5iMwlOS7gFmFNy iykpyEvZ9WpRqIX/aDc9xZT0b58uqtljFOcI4rUxn3ddpYT9N/eCwZYWKxP18RZRy0da pmcQ== X-Gm-Message-State: AC+VfDwzMMozXvRlN4yEN9b6kg2644brJDfdbnwfYy3IisVu4AMRasMA MxdiZRuurPPYrRKxPwILNMHFaTpM+9K0+5bwNsU= X-Google-Smtp-Source: ACHHUZ7AfPl333sQFEZoS8+XsAzLyGa/fd7n5K3R9wLSWEu6GHHgvfqFP4ULp2rIo9kyKf8Tigto8Lpn7RTncK5Glew= X-Received: by 2002:ac2:5dc5:0:b0:4ef:bcb6:a74c with SMTP id x5-20020ac25dc5000000b004efbcb6a74cmr742094lfq.61.1683100724016; Wed, 03 May 2023 00:58:44 -0700 (PDT) MIME-Version: 1.0 References: <1682679641-13652-1-git-send-email-zhaoyang.huang@unisoc.com> In-Reply-To: From: Zhaoyang Huang Date: Wed, 3 May 2023 15:58:21 +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==?= 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 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 (Zh= aoyang 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 168676649 > > > > introduce, that is, 12MB free cma pages 'help' GFP_MOVABLE to keep > > > > draining/fragmenting U&R page blocks until they shrink to 12MB with= out > > > > 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 WMARK_LOW > > > > when being fallback. > > > > > > Can you, please, explain the problem you're solving in more details? > > I am trying to solve a OOM problem caused by slab allocation fail as al= l free pages are MIGRATE_CMA by applying 168676649, which could help to red= uce the fault ration from 12/20 to 2/20. I noticed it introduce the phenome= non which I describe above. > > > > > > If I understand your code correctly, you're effectively reducing 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 than it = is now, which could help to protect U&R be 'stolen' by GFP_MOVABLE. Imagine= this scenario, 30MB total free pages composed of 10MB CMA and 20MB U&R, wh= ile zone's watermark low is 25MB. An GFP_MOVABLE allocation can keep steali= ng U&R pages(don't meet 1/2 criteria) without enter slowpath(zone_watermark= _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 lo= wer to certain zone's watermark instead of when their size become smaller t= han CMA. > > > Also, this is a hot path, please, make sure you're not adding much ov= erhead. > > 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 order, = int migratetype, > if (IS_ENABLED(CONFIG_CMA)) { > /* > * Balance movable allocations between regular and CMA ar= eas 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 easil= y > + * 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 no= n-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 single zone. This fixed 1/2 could lead to different situation on 20% or 50% cma occupation. > > Thanks!