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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 9762EC433E1 for ; Mon, 18 May 2020 07:06:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3E5502067D for ; Mon, 18 May 2020 07:06:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3E5502067D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=sony.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D79CC900003; Mon, 18 May 2020 03:06:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D2B74900002; Mon, 18 May 2020 03:06:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4122900003; Mon, 18 May 2020 03:06:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id A77E7900002 for ; Mon, 18 May 2020 03:06:18 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 70715180AD815 for ; Mon, 18 May 2020 07:06:18 +0000 (UTC) X-FDA: 76828956036.29.mist06_5413931893119 X-HE-Tag: mist06_5413931893119 X-Filterd-Recvd-Size: 3099 Received: from SELDSEGREL01.sonyericsson.com (seldsegrel01.sonyericsson.com [37.139.156.29]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Mon, 18 May 2020 07:06:17 +0000 (UTC) Subject: Re: [PATCH] mm, compaction: Indicate when compaction is manually triggered by sysctl To: Guilherme Piccoli , David Rientjes CC: "Guilherme G. Piccoli" , Andrew Morton , , , Gavin Guo , Mel Gorman References: <20200507215946.22589-1-gpiccoli@canonical.com> <20200507160438.ed336a1e00c23c6863d75ae5@linux-foundation.org> From: peter enderborg Message-ID: <6bf5e178-f2c8-f453-9035-93e31995bb53@sony.com> Date: Mon, 18 May 2020 09:06:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-SEG-SpamProfiler-Analysis: v=2.3 cv=Nc2YKFL4 c=1 sm=1 tr=0 a=kIrCkORFHx6JeP9rmF/Kww==:117 a=IkcTkHD0fZMA:10 a=sTwFKg_x9MkA:10 a=1XWaLZrsAAAA:8 a=-k7fE2aBq4CcJps1nlAA:9 a=QEXdDO2ut3YA:10 X-SEG-SpamProfiler-Score: 0 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 5/11/20 1:26 PM, Guilherme Piccoli wrote: > On Sun, May 10, 2020 at 10:25 PM David Rientjes wrote: >> [...] >> 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. > OK, agreed! Let's forget the kernel log. So, do you think the way to > go is the statsfs, not a zoneinfo stat, a per-node thing? I'm saying > that because kernel mm subsystem statistics seem pretty.."comfortable" > the way they are, in files like vmstat, zoneinfo, etc. Let me know > your thoughts on this, if I could work on that or should wait statsfs. > Thanks, > > > Guilherme I think a trace notification in compaction like kcompad_wake would be good.