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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B7C2C433EF for ; Wed, 10 Nov 2021 13:16:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A8C366115A for ; Wed, 10 Nov 2021 13:16:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A8C366115A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E82B56B006C; Wed, 10 Nov 2021 08:16:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E31D86B0071; Wed, 10 Nov 2021 08:16:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFA1E6B0072; Wed, 10 Nov 2021 08:16:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id BE0406B006C for ; Wed, 10 Nov 2021 08:16:27 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6D92381CFB for ; Wed, 10 Nov 2021 13:16:27 +0000 (UTC) X-FDA: 78793069614.28.B62D9AA Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf07.hostedemail.com (Postfix) with ESMTP id B852F10004DC for ; Wed, 10 Nov 2021 13:16:24 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 5B84F61107; Wed, 10 Nov 2021 13:16:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636550183; bh=7rx1dmvlEOjFTEd/aBQFfM7ZdEvL6pnd5/H4ff/lqzY=; h=From:To:Cc:Subject:Date:In-Reply-To:From; b=Z1InjpUCfsgx59mG67L6AmWPpl+SWCeQjlUS9w4FjZknj9teUe4TbGB2A6KMKgiX+ obJLUvwr3NiHspqBn65tFTgRc094+ISarDC+ChBYRRCwqculyxCtcSgl8PGHwPAzM/ YYMrl6Bl0Y2fAcwnpBzRGEPY/hk3Y/OQIbeZVq+AE+Xp4cWmAqgSdrSuViSK32hI6k Z3fhhJ2M25VqdriNYKe7dA7fKytPF823F2GDgrcPsOdJKZTi5JelRMG0Kjqf/53aqr 1YfqmKcIesdsXApQb+dDWvvXyE2FqkkQcvi98zcxiysA031HX/AtZXTyWfA977pTGD 4cyDN1WJSTnVA== From: SeongJae Park To: Xin Hao Cc: sjpark@amazon.de, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V1 2/2] mm/damon: Add 'age' of region tracepoint support Date: Wed, 10 Nov 2021 13:16:21 +0000 Message-Id: <20211110131621.18221-1-sj@kernel.org> X-Mailer: git-send-email 2.17.1 In-Reply-To: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B852F10004DC X-Stat-Signature: irh84c99s6ycf5i9fo6rtwmdw8o6gfn7 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Z1InjpUC; spf=pass (imf07.hostedemail.com: domain of sj@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1636550184-670352 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000013, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 10 Nov 2021 20:13:14 +0800 Xin Hao wrote: > In patch "mm/damon: add a tracepoint", it adds a > tracepoint for DAMON, it can monitor each region > for each aggregation interval, Now the region add > a new 'age' variable, some primitive would calculate > the priority of each region as a weight, there put it > into tracepoint, so we can easily track the change of > its value through perf or damon-tools. DAMON calculates the age using the address range and nr_accesses of the region, which are already in the tracepoint. In other words, user space can calculate the age on their own. Therefore I thought putting age in the tracepoint as adding unnecessary information, at the moment of the implementation. Of course, I would missing some use cases that need this information in the tracepoint. Furthermore, adding just one more value in the tracepoint wouldn't incur a real issue. But, I'd like to know why this is necessary and how much benefit it provides. Xin, could you please share that? Thanks, SJ > > Signed-off-by: Xin Hao > --- > include/trace/events/damon.h | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/include/trace/events/damon.h b/include/trace/events/damon.h > index 2f422f4f1fb9..99ffa601e351 100644 > --- a/include/trace/events/damon.h > +++ b/include/trace/events/damon.h > @@ -22,6 +22,7 @@ TRACE_EVENT(damon_aggregated, > __field(unsigned long, start) > __field(unsigned long, end) > __field(unsigned int, nr_accesses) > + __field(unsigned int, age) > ), > > TP_fast_assign( > @@ -30,11 +31,13 @@ TRACE_EVENT(damon_aggregated, > __entry->start = r->ar.start; > __entry->end = r->ar.end; > __entry->nr_accesses = r->nr_accesses; > + __entry->age = r->age; > ), > > - TP_printk("target_id=%lu nr_regions=%u %lu-%lu: %u", > + TP_printk("target_id=%lu nr_regions=%u %lu-%lu: %u %u", > __entry->target_id, __entry->nr_regions, > - __entry->start, __entry->end, __entry->nr_accesses) > + __entry->start, __entry->end, > + __entry->nr_accesses, __entry->age) > ); > > #endif /* _TRACE_DAMON_H */ > -- > 2.31.0