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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21A8CC433E0 for ; Sun, 24 Jan 2021 22:54:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9334122226 for ; Sun, 24 Jan 2021 22:54:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9334122226 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BF3CB6B0005; Sun, 24 Jan 2021 17:54:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BA6336B0007; Sun, 24 Jan 2021 17:54:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6E166B0008; Sun, 24 Jan 2021 17:54:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0121.hostedemail.com [216.40.44.121]) by kanga.kvack.org (Postfix) with ESMTP id 90A966B0005 for ; Sun, 24 Jan 2021 17:54:51 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 44D99181AEF3C for ; Sun, 24 Jan 2021 22:54:51 +0000 (UTC) X-FDA: 77742175182.12.bead45_3e043eb27580 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 1A7E9180555DE for ; Sun, 24 Jan 2021 22:54:51 +0000 (UTC) X-HE-Tag: bead45_3e043eb27580 X-Filterd-Recvd-Size: 4946 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Sun, 24 Jan 2021 22:54:50 +0000 (UTC) Received: by mail-pj1-f44.google.com with SMTP id a20so4235851pjs.1 for ; Sun, 24 Jan 2021 14:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=2M4GL8HSPHB4CnNzd+6jrJbF6ak+SGdq4mvPyBQeBag=; b=kqFVBKhqD95318pJbQOIvxd5hAbt2uqIPrp1brXnxNxQ36zAXpQ5H/oiH7qgB8jGrs /Wb8zT5XkZ+Hte6MoWxMz1N7wAzDjS+lAcfH32hNC/SrLgXUjo5BZA10ULzWT5obIlRH lWfIB+JSZAasYIrCG8TUcN8ksaDOMalcGvwtB+aPTO/Y3AP7g1W5JDwRcqVN0w2Z+Cud HO3slEj8yrqqoRlqQ58ng2RM8E2bV37r3wj9mTvIlLvIfpwiF/E9kZtWi11whY4RVYyj Za80tnv00CqTwTa3XNSHu0LY0AKTfMIWhjOc52d6WPds3///LKPO3Ncg9mUusmLaufbu Eu9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=2M4GL8HSPHB4CnNzd+6jrJbF6ak+SGdq4mvPyBQeBag=; b=DMd8CaLbC9bXGIWuQ6n3HmK/S89ZVJqa3cafmtoGH7kZyzpnPWn+Yg/2nv01off0dt IOb3m2u2xE1Hdy936wBfzk+bP18B2U4kfds0NWVMYTpYT3empUhyrt3W2DTHwxn52MXQ HI3uOAq/kO8a8TR7PR26AJ2RCs203Q2sgnqhn83jQBp1DJPeffOZyqtKCagJFtNnVvnY J3CEeZKEIbydfqQagL2e2wv+u+e+FtwR+5k0Nf2rQTDdRleEz5p8yT0SXz1L5knPyWw4 ih8NQfSCN6JIt9pLQj8ckiNlC5vhBhVoju89vTXiaznaWLoF2e838pWJnS+YJt2xf3bT sTNA== X-Gm-Message-State: AOAM531TScnStpLXXRhjgt5h1QphnBEGguL3mMNMXYvK6Y8KN/tl+7o5 8zadgl9VdJriFJD1cTzYN358Hw== X-Google-Smtp-Source: ABdhPJxFkKarmvQr7zce29NhIu0fFt7Pbg2oEVXhpM8d3urzv2f1NT6QsyGJCc4q7ItdIFsEivMOaw== X-Received: by 2002:a17:90a:5914:: with SMTP id k20mr18538440pji.199.1611528889521; Sun, 24 Jan 2021 14:54:49 -0800 (PST) Received: from [2620:15c:17:3:4a0f:cfff:fe51:6667] ([2620:15c:17:3:4a0f:cfff:fe51:6667]) by smtp.gmail.com with ESMTPSA id c5sm14845346pgt.73.2021.01.24.14.54.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Jan 2021 14:54:48 -0800 (PST) Date: Sun, 24 Jan 2021 14:54:47 -0800 (PST) From: David Rientjes To: Vlastimil Babka cc: Charan Teja Reddy , akpm@linux-foundation.org, mhocko@suse.com, khalid.aziz@oracle.com, ngupta@nitingupta.dev, vinmenon@codeaurora.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V3] mm/compaction: correct deferral logic for proactive compaction In-Reply-To: <80a1a433-c520-4c73-61ce-55cf33739fc5@suse.cz> Message-ID: <627a82ec-94ef-a233-4637-28bc82a886e9@google.com> References: <1610989938-31374-1-git-send-email-charante@codeaurora.org> <80a1a433-c520-4c73-61ce-55cf33739fc5@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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, 20 Jan 2021, Vlastimil Babka wrote: > On 1/19/21 8:26 PM, David Rientjes wrote: > > On Mon, 18 Jan 2021, Charan Teja Reddy wrote: > > > >> should_proactive_compact_node() returns true when sum of the > >> weighted fragmentation score of all the zones in the node is greater > >> than the wmark_high of compaction, which then triggers the proactive > >> compaction that operates on the individual zones of the node. But > >> proactive compaction runs on the zone only when its weighted > >> fragmentation score is greater than wmark_low(=wmark_high - 10). > >> > >> This means that the sum of the weighted fragmentation scores of all the > >> zones can exceed the wmark_high but individual weighted fragmentation > >> zone scores can still be less than wmark_low which makes the unnecessary > >> trigger of the proactive compaction only to return doing nothing. > >> > >> Issue with the return of proactive compaction with out even trying is > >> its deferral. It is simply deferred for 1 << COMPACT_MAX_DEFER_SHIFT if > >> the scores across the proactive compaction is same, thinking that > >> compaction didn't make any progress but in reality it didn't even try. > > > > Isn't this an issue in deferred compaction as well? It seems like > > deferred compaction should check that work was actually performed before > > deferring subsequent calls to compaction. > > Direct compaction does, proactive not. > > > In other words, I don't believe deferred compaction is intended to avoid > > checks to determine if compaction is worth it; it should only defer > > *additional* work that was not productive. > > Yeah, that should be more optimal. > Charan, is this something you'd like to follow up on, or should I take a look instead? Thanks!