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 63457C77B78 for ; Tue, 2 May 2023 22:01:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8417B6B0071; Tue, 2 May 2023 18:01:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CA726B0072; Tue, 2 May 2023 18:01:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B9406B0074; Tue, 2 May 2023 18:01:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from out-53.mta1.migadu.com (out-53.mta1.migadu.com [95.215.58.53]) by kanga.kvack.org (Postfix) with ESMTP id 46D666B0071 for ; Tue, 2 May 2023 18:01:45 -0400 (EDT) Date: Tue, 2 May 2023 15:01:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1683064903; h=from:from: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; bh=AMmiYuTgPnt6TKBna33T3vw4E7dgnbLqqVwuuubJ7mY=; b=Qrh3b92Q6myey0WwoiNsP/Q8uimN60HFMFCE4kXLji9n8e1wLJqsysP5BbT5QB4z509GV8 5PBgbpCcFUI459Aw/kSKrRQLYHZzG2/Y+GEbyxvUEAXdkQ6cgy4VcLYm73fYMZOcnjCYL2 R7V8wVa1iG3XF9V7Mz8DF5W95PDT7ow= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: =?utf-8?B?6buE5pyd6ZizIChaaGFveWFuZyBIdWFuZyk=?= Cc: Andrew Morton , Roman Gushchin , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Zhaoyang Huang , =?utf-8?B?546L56eRIChLZSBXYW5nKQ==?= Subject: Re: =?utf-8?B?562U5aSNOiBbUEFUQ0g=?= =?utf-8?Q?=5D?= mm: optimization on page allocation when CMA enabled Message-ID: References: <1682679641-13652-1-git-send-email-zhaoyang.huang@unisoc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT 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, May 02, 2023 at 12:12:28PM +0000, 黄朝阳 (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 168676649 > > > introduce, that is, 12MB free cma pages 'help' GFP_MOVABLE to keep > > > draining/fragmenting U&R page blocks until they shrink to 12MB 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 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 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 phenomenon 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, 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_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 lower to certain zone's watermark instead of when their size become smaller than CMA. > > Also, this is a hot path, please, make sure you're not adding much 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 order, 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) { page = __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? Thanks!