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=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,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 5FA93C54E8E for ; Mon, 11 May 2020 01:25:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2355B208CA for ; Mon, 11 May 2020 01:25:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="XWwCZN3j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2355B208CA 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 A7D9D90003B; Sun, 10 May 2020 21:25:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A04D78E0001; Sun, 10 May 2020 21:25:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CDEB90003B; Sun, 10 May 2020 21:25:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id 711A48E0001 for ; Sun, 10 May 2020 21:25:01 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 290EC40F4 for ; Mon, 11 May 2020 01:25:01 +0000 (UTC) X-FDA: 76802694402.28.event95_2bc9a308e2316 X-HE-Tag: event95_2bc9a308e2316 X-Filterd-Recvd-Size: 5234 Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Mon, 11 May 2020 01:25:00 +0000 (UTC) Received: by mail-pf1-f194.google.com with SMTP id 18so4010165pfv.8 for ; Sun, 10 May 2020 18:25:00 -0700 (PDT) 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 :user-agent:mime-version; bh=rrpue9ELDAyjtjXQonJqUPBUAIMsAtBRTq6A+RPQWpw=; b=XWwCZN3jW3/5HtRXyFm+DTTr5MV4v9xZjc1MlfUlO//spcTx5rVeX/uovT5jprL0QC GQBFO+UtZrdtb4gEq5y1skPW8asQ/rag5f77L0I8AdH/AgEwoX2wDVEK8OLDK0WU4rU4 JCutFIXlcwaGirD1TnrQ320raqdIyH4ZdVA2bezfFFl98GBrnI+h0FipAMm8s6CCivlm JubRMJELEpK6EZOJZ5sw4hB8NTz1mu7rjH69Bb56gDerLBtPO2oFkyx4oGq2WrV7YkG/ rPExuNrXFDCLfmqSwBwP9MpyZliK9c+xNBOlpLmAerKY0/Pil4n+9Dp9mAXOmzLzyi9Y 1N+Q== 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:user-agent:mime-version; bh=rrpue9ELDAyjtjXQonJqUPBUAIMsAtBRTq6A+RPQWpw=; b=SJH315GLfDifIGqTfEj0TBx/hL0APXGWSi0ERPuKxLsVjaKYcutKkXQzM4+WFIQh9h e+ZccwPYXjGBlcz8KCNt7igOkoI0t+lq1jjZ80n8lSz1BK/48oB2W4U8Wup+vROcLcEG w2DGLbdemfJz2qWIqb0v/sbmRl/bhz758V2fK9/2fBKA4hphiwBSH+X8+FZL72VZD4iS kRBWE8IsAGHFzs20sn+4mQPOLS5CyvxyjAMpkxnb81Js4FFJqfsY0i4RrXk/6OUGW5c1 Uaa5ZVp8QDXHxBesPQ9qEiKNtG6wt0SqcYyxsBsVpdKzw6NQ4FrkmUFHpWgZSUKfK5AV hSmQ== X-Gm-Message-State: AGi0PuZmNb7aHgQUDfJRRQDNtEhOwPeFYci1a/JqilzbI2Xi7qT1YJ0n r5pG+xpS27231zi+Iana/I0M5w== X-Google-Smtp-Source: APiQypJrh7BKHwezP7S81MyJCWTh95bZ2XZG16s2AtPiogeoGAV6AtXRKla8hC6TTMm92E+FhkmvSQ== X-Received: by 2002:a63:792:: with SMTP id 140mr7940224pgh.65.1589160299547; Sun, 10 May 2020 18:24:59 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id z7sm7622992pff.47.2020.05.10.18.24.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 May 2020 18:24:58 -0700 (PDT) Date: Sun, 10 May 2020 18:24:58 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Guilherme Piccoli cc: "Guilherme G. Piccoli" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Gavin Guo , Mel Gorman Subject: Re: [PATCH] mm, compaction: Indicate when compaction is manually triggered by sysctl In-Reply-To: Message-ID: References: <20200507215946.22589-1-gpiccoli@canonical.com> <20200507160438.ed336a1e00c23c6863d75ae5@linux-foundation.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) 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 Fri, 8 May 2020, Guilherme Piccoli wrote: > On Fri, May 8, 2020 at 3:31 PM David Rientjes wrote: > > It doesn't make sense because it's only being done here for the entire > > system, there are also per-node sysfs triggers so you could do something > > like iterate over the nodemask of all nodes with memory and trigger > > compaction manually and then nothing is emitted to the kernel log. > > > > There is new statsfs support that Red Hat is proposing that can be used > > for things like this. It currently only supports KVM statistics but > > adding MM statistics is something that would be a natural extension and > > avoids polluting both the kernel log and /proc/vmstat. > > Thanks for the review. Is this what you're talking about [0] ? Very interesting! > Exactly. > Also, I agree about the per-node compaction, it's a good point. But at > the same time, having the information on the number of manual > compaction triggered is interesting, at least for some users. What if > we add that as a per-node stat in zoneinfo? > The kernel log is not preferred for this (or drop_caches, really) because the amount of info can causing important information to be lost. We don't really gain anything by printing that someone manually triggered compaction; they could just write to the kernel log themselves if they really wanted to. The reverse is not true: we can't suppress your kernel message with this patch. Instead, a statsfs-like approach could be used to indicate when this has happened and there is no chance of losing events because it got scrolled off the kernel log. It has the added benefit of not requiring the entire log to be parsed for such events.