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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 773BFCE79DA for ; Wed, 20 Sep 2023 14:32:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E78C06B017A; Wed, 20 Sep 2023 10:32:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E29226B017C; Wed, 20 Sep 2023 10:32:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D17876B0181; Wed, 20 Sep 2023 10:32:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C12926B017A for ; Wed, 20 Sep 2023 10:32:09 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8A4E41CAB17 for ; Wed, 20 Sep 2023 14:32:09 +0000 (UTC) X-FDA: 81257215578.14.D8064A2 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf19.hostedemail.com (Postfix) with ESMTP id 9E9201A0037 for ; Wed, 20 Sep 2023 14:32:04 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of "SRS0=i/f/=FE=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=i/f/=FE=goodmis.org=rostedt@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695220326; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MY2SJYQZ6LN+oQqEiFRCv0nllsUa6LdBsI835slusak=; b=kKQSo72zfqyhJy0YRCplMkL7xvVBtVZv+alhodViZXDgKSSkv5BDPg8SnaDGf3k8YdERP6 22SuFjHyco7V1dO5PRS8HIb0Ux20lJP93o6udPWQ+9TUqQx5nRhfyh7FsQkIGkL77/gVSR 4QueK2iSoDr+LEsomz8rtFouxPCixAg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695220326; a=rsa-sha256; cv=none; b=m/ZS+wr2jSK8VW0aN9J602iG7v4Xxjs+BhPHOd/o5qA/H3gH2IaJDQ3AElEmkl/v2rdVRA 5L9bHoZ3C6y3Hk98iQnKk1l0pfrVZ0w7m6dxTfbtaXREdY+3itQUfMzXziwR+5+V63TJAK mHYLFOZldIUeV2TrP2xJe1lVs5XMhGQ= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of "SRS0=i/f/=FE=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=i/f/=FE=goodmis.org=rostedt@kernel.org"; dmarc=none Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 86C8BCE1B4B; Wed, 20 Sep 2023 14:32:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90317C433C7; Wed, 20 Sep 2023 14:31:58 +0000 (UTC) Date: Wed, 20 Sep 2023 10:32:33 -0400 From: Steven Rostedt To: =?UTF-8?B?6rmA7J6s7JuQ?= Cc: "yuzhao@google.com" , "tjmercier@google.com" , "kaleshsingh@google.com" , "akpm@linux-foundation.org" , "vbabka@suse.cz" , "hannes@cmpxchg.org" , "linux-kernel@vger.kernel.org" , "linux-trace-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "jaewon31.kim@gmail.com" Subject: Re: (2) [PATCH] vmscan: add trace events for lru_gen Message-ID: <20230920103233.145ac387@gandalf.local.home> In-Reply-To: <20230920074948epcms1p82d18c2f4d6a0b5699d50fc419b9ba9fe@epcms1p8> References: <20230919095927.5a964094@gandalf.local.home> <20230919025216.1878-1-jaewon31.kim@samsung.com> <20230920074948epcms1p82d18c2f4d6a0b5699d50fc419b9ba9fe@epcms1p8> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 8qpj5e5kbn5xfyzzmyds1e6ab171s8yb X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 9E9201A0037 X-Rspam-User: X-HE-Tag: 1695220324-754716 X-HE-Meta: U2FsdGVkX188Uay0zIwP66i9JVZdF/gzNy9aHM4nuInkSJMfSmvNdyVWh1hufq1686uVvc8UZX64naSzG7V6nlnvelBpyUbA+stf3if//xNSJ03jNyXbXyA1DWjvPj5uIAMzSkiR9+Ei12aTrHuHRg005UR5CqoUtBUHO3BgDwJun59jEaaKD1g+PfdjtF8KWt8YA6ttMLmwHeFe3OZO1EaB8Tprcs6EjFPVfP9iMrSpHR7ioh0rnVxNM5KnGes5xXNQbTAEcPGoR2ElSWyFvD2FWypglkLk+Sfdl1I8OG+Y7nZkigBenf2J6XYi8y3k7yA2Lu7guCdc1s0gZ+4OZ2RVLr5Wq8IkraezqROkD9aPoRSbKgL3m1So1BVj9zFrNrq8HbgqiYeQuMXSi5cl0+F7o8ySgOkKmbD6li+jJNO6Gus1sPja73YoH0SpZcxyk7+gESc4G2FCSGEqINRDq7jcGfxU/Z1I75BSik0+/oVg6Iqp+WOegtbmkBi4McbUXuNA2D8Gpp0oKcxnE+Fr7FcWYujXQy/GjQn2uibRM6LZEQHlvIh4w0gDsW5p1QzLWb/Byio1IUWOcOeO+Llj+hTHvSCx7W6bE4oj0KIMefv/p5yEroE/En72iE6VCKxzObqAOXqrfW4RWHWTZ1LGvOrJSBLqLUQNaeOxZg9bJ8S6UXjkmrLHYI89hVJa6m5cbBr+BFTyi+qwRaakynKrHuXHpZMNCJOVee0bi+ZO14LXr1/uJ5z9HeCrUhql3rLQGulSBR6rjGkCNtdvFoedjI/Y+b/80gRC5N/1bPDlbmnCn+ZnuwLB5ticgDC8mhOKie62LyOeu4Wu8H9OGfKSHB8Qb1gSAtOOAOZ96l2RoN5olBnAHIfGQNinBHe8WfsVM7wZwRihmAFqX4OwJOWkU7E47riXwpCFfYq6UB+5/hzDpKU2Jo8b41i8KLT3LXbh+moSw2IhOHRA+8yVWlZ 2/4G2F7S eNrJKlln+CVVBbvDCymnpHcRj0oQZq/m5p3/t8o6H1B6m4+PC+TRySLomi/4V5cG6GxKE3KPoHFynr5oMvt5qAfBI+SZ4824g+hISrgItWff2Mdz0bL8nTUA4dmuuUH7xkv3oSk9G9ewsQm2uo99xa5HTP5+2p7bRZjSZ4ouGv+jn5QXgPta0Rq9heGnTXZoH+ZYIFvC5D8njboU/lULYqNhC97IZ4nCf/T83Opjczb0zatWWuxPufLC10gvO4ACMhwBXzksVyV3p4JKYiKiVzSXFSAa9KnGYyYQwNVhVq/JoK1K3wB5rsJ0r9j3N5ingdO272RNG5guWAXVz4RuUy1yN5uvewqg+e5yL5hWoN+5r6Kxwg4xEkxjCfg0VjJ5jZAnTx1UGBVl9EZbLVv+cXVhvm53Ht8k30wzKp5N6ItT2TjRwtnmrZemL3xeftBlHj7mx++vLFPjywCdNJwWAhHWhdDjMaLLcEFRV8Gv/cWc/V1inyJ8MZEwFHAgMaqx9Q/EOF9vl3XcqZWleQC3RRBYCMA== 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 Sep 2023 16:49:48 +0900 =EA=B9=80=EC=9E=AC=EC=9B=90 wrote: > Great. Thank you for your comment. >=20 > For the putting the struct scan_control *sc inside the trace, > I couldn't do that because struct scan_control is defined in mm/vmscan.c. > I think I should not move it to a seperate header file. Well if you ever decide to do so, one thing to do is to move the trace/events/vmscan.h into mm/ as trace_vmscan.h so that it would have access to local header files. Then all you need to do is to move the struct scan_control into a local mm/X.h header file. >=20 > As you may expect, I just made this by copying the existing > trace_mm_vmscan_lru_isolate and trace_mm_vmscan_lru_shrink_inactive >=20 > I've tried to change like this. > Would this be good for you? The below looks fine to me. Thanks. -- Steve >=20 >=20 > --- a/include/trace/events/vmscan.h > +++ b/include/trace/events/vmscan.h > @@ -327,7 +327,7 @@ TRACE_EVENT(mm_vmscan_lru_isolate, > __print_symbolic(__entry->lru, LRU_NAMES)) > ); > =20 > -TRACE_EVENT(mm_vmscan_lru_gen_scan, > +TRACE_EVENT_CONDITION(mm_vmscan_lru_gen_scan, > TP_PROTO(int highest_zoneidx, > int order, > unsigned long nr_requested, > @@ -339,6 +339,8 @@ TRACE_EVENT(mm_vmscan_lru_gen_scan, > =20 > TP_ARGS(highest_zoneidx, order, nr_requested, nr_scanned, nr_skip= ped, nr_taken, isolate_mode, lru), > =20 > + TP_CONDITION(nr_scanned), > + > TP_STRUCT__entry( > __field(int, highest_zoneidx) > __field(int, order) > @@ -494,7 +496,6 @@ TRACE_EVENT(mm_vmscan_lru_gen_evict, > TP_ARGS(nid, nr_reclaimed, stat, priority, file), > =20 > TP_STRUCT__entry( > - __field(int, nid) > __field(unsigned long, nr_reclaimed) > __field(unsigned long, nr_dirty) > __field(unsigned long, nr_writeback) > @@ -504,6 +505,7 @@ TRACE_EVENT(mm_vmscan_lru_gen_evict, > __field(unsigned int, nr_activate1) > __field(unsigned long, nr_ref_keep) > __field(unsigned long, nr_unmap_fail) > + __field(int, nid) > __field(int, priority) > __field(int, reclaim_flags) > ), >=20 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -5131,10 +5131,9 @@ static int scan_folios(struct lruvec *lruvec, stru= ct scan_control *sc, > __count_memcg_events(memcg, PGREFILL, sorted); > __count_vm_events(PGSCAN_ANON + type, isolated); > =20 > - if (scanned) > - trace_mm_vmscan_lru_gen_scan(sc->reclaim_idx, sc->order, > - MAX_LRU_BATCH, scanned, skipped, isolated, > - sc->may_unmap ? 0 : ISOLATE_UNMAPPED, typ= e); > + trace_mm_vmscan_lru_gen_scan(sc->reclaim_idx, sc->order, MAX_LRU_= BATCH, > + scanned, skipped, isolated, > + sc->may_unmap ? 0 : ISOLATE_UNMAPPED, type); >=20 >=20 >=20 > >