Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3121311pxb; Fri, 12 Feb 2021 09:39:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJwDi1eQwkhMCuwGyyIT497uUtlNDJQB+h1psZZCX93/vWr8w+3R5YaiC1Vpe43X8fFBfcEG X-Received: by 2002:a17:906:17d5:: with SMTP id u21mr4160472eje.541.1613151594085; Fri, 12 Feb 2021 09:39:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613151594; cv=none; d=google.com; s=arc-20160816; b=qKA6uqveUpP2ZWMIIaOi8vpR6Iq4Lz8hqD5Kq18n3/hjUnNhK3NolnE+aFX6c2qcEt 0DtEfe4CWfNwWPa6jDKJCmki53Q9yb38zForHGFmmzL7MrjnubKiye1D6Afk28R/zFl2 ikkDIX9WkYhPpskJKvfi4PvGhzPTAYkmQ/NfK/Ijym/wbTKp26EEZs//+wwOH0WXA33G gECMwUECk9DkyQDoP83zzv5N493Mvd1E/PL55wh7qGqSe8WYvKL7IrTpRWeRRopg52lY 03i64pIcIDiAUcmCR8HGW0JC3M56dVYPoeh09TSUNQtYLdhr+ayElw98HhEhHLbS6AsO vAeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=iJ5Sw1V7c9PoBGA3cPkrOVVAGzBLlMApzoG6W2FyI2o=; b=LG12eYJDOfcVSpL5D1NUSzHZWTjAIeh5T0GJFlWDAueaBvzervw3pbzhTrgUXQAI98 dd6a12IyrtCzBgO+pQmtmWUtXFV+tFRahdw7AWxkBEVuUEKRsJMIaYaZl1Bjn6ClMIME qP7dq77vED4HSm6mLJgKULlmCOOXC++nL77EXaOLpWC2WzQ+63oY0GyF2L+z5ES8zdoy 6xCAxKNx+oV8TW5xs1+CVc65WfwPWCEWeZe1zsHHEclDCxn1YZVCmMjQYy9rGpt3PaNn SzDcYWQ6k7a46sp/gxLB9H8CSAfyTI8xSLXX19TpQ1da6zxfW3Dk+3IIOApHhIm3cLBd fzhA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bz22si6588739ejc.658.2021.02.12.09.39.31; Fri, 12 Feb 2021 09:39:54 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230489AbhBLRiz (ORCPT + 99 others); Fri, 12 Feb 2021 12:38:55 -0500 Received: from mx2.suse.de ([195.135.220.15]:34364 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229611AbhBLRiy (ORCPT ); Fri, 12 Feb 2021 12:38:54 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 7C549AD19; Fri, 12 Feb 2021 17:38:13 +0000 (UTC) Subject: Re: [PATCH V2] mm: compaction: update the COMPACT[STALL|FAIL] events properly To: Charan Teja Reddy , akpm@linux-foundation.org, rientjes@google.com, linux-mm@kvack.org Cc: vinmenon@codeaurora.org, linux-kernel@vger.kernel.org References: <1613151184-21213-1-git-send-email-charante@codeaurora.org> From: Vlastimil Babka Message-ID: <9d12dc04-9cf0-8dd1-5fb3-9a5f8e34d23f@suse.cz> Date: Fri, 12 Feb 2021 18:38:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <1613151184-21213-1-git-send-email-charante@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/12/21 6:33 PM, Charan Teja Reddy wrote: > By definition, COMPACT[STALL|FAIL] events needs to be counted when there > is 'At least in one zone compaction wasn't deferred or skipped from the > direct compaction'. And when compaction is skipped or deferred, > COMPACT_SKIPPED will be returned but it will still go and update these > compaction events which is wrong in the sense that COMPACT[STALL|FAIL] > is counted without even trying the compaction. > > Correct this by skipping the counting of these events when > COMPACT_SKIPPED is returned for compaction. This indirectly also avoid > the unnecessary try into the get_page_from_freelist() when compaction is > not even tried. > > There is a corner case where compaction is skipped but still count > COMPACTSTALL event, which is that IRQ came and freed the page and the > same is captured in capture_control. > > Signed-off-by: Charan Teja Reddy Acked-by: Vlastimil Babka Thanks! > --- > > changes in V1: https://lore.kernel.org/patchwork/patch/1373665/ > > mm/compaction.c | 8 ++++++++ > mm/page_alloc.c | 2 ++ > 2 files changed, 10 insertions(+) > > diff --git a/mm/compaction.c b/mm/compaction.c > index 190ccda..104ebef 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -2487,6 +2487,14 @@ static enum compact_result compact_zone_order(struct zone *zone, int order, > */ > WRITE_ONCE(current->capture_control, NULL); > *capture = READ_ONCE(capc.page); > + /* > + * Technically, it is also possible that compaction is skipped but > + * the page is still captured out of luck(IRQ came and freed the page). > + * Returning COMPACT_SUCCESS in such cases helps in properly accounting > + * the COMPACT[STALL|FAIL] when compaction is skipped. > + */ > + if (*capture) > + ret = COMPACT_SUCCESS; > > return ret; > } > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 519a60d..531f244 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -4152,6 +4152,8 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order, > memalloc_noreclaim_restore(noreclaim_flag); > psi_memstall_leave(&pflags); > > + if (*compact_result == COMPACT_SKIPPED) > + return NULL; > /* > * At least in one zone compaction wasn't deferred or skipped, so let's > * count a compaction stall >