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 EF2CEE7849C for ; Sun, 1 Oct 2023 23:41:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EBAB6B0184; Sun, 1 Oct 2023 19:41:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69B4B6B0185; Sun, 1 Oct 2023 19:41:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5636B6B0187; Sun, 1 Oct 2023 19:41:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 474556B0184 for ; Sun, 1 Oct 2023 19:41:31 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 05964C0293 for ; Sun, 1 Oct 2023 23:41:31 +0000 (UTC) X-FDA: 81298516782.10.E44198F Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf11.hostedemail.com (Postfix) with ESMTP id 39DFC4000A for ; Sun, 1 Oct 2023 23:41:29 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dhp9abHx; spf=pass (imf11.hostedemail.com: domain of jaewon31.kim@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=jaewon31.kim@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696203689; a=rsa-sha256; cv=none; b=mi6tVkZjCFTfODgRViinz8UtKCVT8d5TIRXhNZ0PVe8VU7xJUpBLdnC+jQkdUVDc1JCL6d aX0ekDvadt7tr50VlnMM4vRrKYY+oTH2OL6Q7Vari5ucJU8EzF85EYWKk80gcXyqRrDp8m BmcqVU/IzryPGwhUBTFUPw+HS1SAgfs= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=dhp9abHx; spf=pass (imf11.hostedemail.com: domain of jaewon31.kim@gmail.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=jaewon31.kim@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696203689; 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:dkim-signature; bh=WCw6Qf7uaEQJpAr4uqh6Rw9ragn/5xvPfhWBouy9/U4=; b=PtD4DltdUO681vgyI/1KORa6OoDnMsVDARJFVxFNhKD3J4TvTeP4JLaHOgUtJbLKwqzVwk uFtxg46VS4aKHoCGxuYuFMXGnXIvXRDiXTlOD964yExJPGPVEwO6moyOlhEdRk4nNIV0zC YXCCNb9VRlENQi1VvuLkBfoHvPvaVxI= Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-98273ae42d0so463920566b.0 for ; Sun, 01 Oct 2023 16:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696203687; x=1696808487; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WCw6Qf7uaEQJpAr4uqh6Rw9ragn/5xvPfhWBouy9/U4=; b=dhp9abHxI0lJPdaAxmldDvX6YbUxKMUWbz1API3j0Vi2E3zQ74+AWcq6ELNEUyw952 uviZ9A4htlfeP1oazvj/8UTjcZ7j1v7Vruz+Hw/hYbT8N+d7i/3DCyQWTUbujpe57hHY nUVCv/AFLZz5lzqnCzUCL26Ogv0Oazgtm9aFFvbUhdVJ9ItEH72A9th7YK8Knzuaf4d9 DxzCHeGRYSRMyRNknkBBi1pdsab4YmItXVRAr7PmYOkyeWw7D2gH+g6joC6ZyWjy9Lzb FeSanR3pIGzc3A+paKZBeoOLXELNx5TeC0XabD6o0ylPW2oxcQDNcT1e7iw+mzvw1Msn zbVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696203687; x=1696808487; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WCw6Qf7uaEQJpAr4uqh6Rw9ragn/5xvPfhWBouy9/U4=; b=At3DQvULY5U/DvylCdSvx9TS3/9m13S/qtrBpaACsiEsiIlu7IJYDPCwyxm7FijHHJ S7kzYoaqVrtsYywls9JV4Be84jo/enflw+9HaBvKM1o+lUivof526tzzuLD3fia59Leb gTbpiPB/BcGAaE9shBnBnWdl4p7NFANMAS3hVOFv6IoJSWTUIZCoAO99V4j2HF+TeJ6Z 0vZCOIQrxmsGbQBsIYGy+Brhds0/ubmOE3ZN/QZBia3khizeOcEcA0tAya4MOteZNrAl KxFrjI9K7uO67jjj1FcHSBflJqKw7apt/CcKM8PYmoZNw3VZz+SVIKzDSleMjF3X3by1 NUHg== X-Gm-Message-State: AOJu0YylrbwfYQ7XEC560tgNMg7Ug1cXjSQIefW1aB5QSfgGyKNz+vzS k0YRro9Fn0zB+DQiqcmZqb/nL2Oejqn7VvVtvXc= X-Google-Smtp-Source: AGHT+IHmk1YnWFiKu+cNPgBJIsBy+qelPFXYFGFUBywv2fg/TeAZnUdFpQPAGdzT3mP0V8HkRBBxzbHmZFy+EE8NVoI= X-Received: by 2002:a05:6402:430f:b0:522:580f:8304 with SMTP id m15-20020a056402430f00b00522580f8304mr8767814edc.1.1696203687373; Sun, 01 Oct 2023 16:41:27 -0700 (PDT) MIME-Version: 1.0 References: <20230926051035epcms1p312b531bba2c17bb763b6f046a45c86da@epcms1p3> <20230926042250.6028-1-jaewon31.kim@samsung.com> <20230926073333epcms1p14c9798232b395007eb20becb5dbc4b4e@epcms1p1> <20230926141519epcms1p5b7808c768df48647516f458529e4e3c8@epcms1p5> In-Reply-To: <20230926141519epcms1p5b7808c768df48647516f458529e4e3c8@epcms1p5> From: Jaewon Kim Date: Mon, 2 Oct 2023 08:41:15 +0900 Message-ID: Subject: Re: [PATCH v4] vmscan: add trace events for lru_gen To: jaewon31.kim@samsung.com Cc: Yu Zhao , "rostedt@goodmis.org" , "tjmercier@google.com" , "kaleshsingh@google.com" , "akpm@linux-foundation.org" , "vbabka@suse.cz" , "hannes@cmpxchg.org" , "sj@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-trace-kernel@vger.kernel.org" , "linux-mm@kvack.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 39DFC4000A X-Stat-Signature: mf5xm8zyxnfa5ubk8oaxjhb7rejjfnwz X-Rspam-User: X-HE-Tag: 1696203689-244532 X-HE-Meta: U2FsdGVkX19mDsPEuHBqrWcMT5EAcocPiiQ3PO4l/CdTNfaRnfnuDbZavo/mrqEOsDv2VbrnX9sPx/ee8P5hQ213nIE7Did4FkHJUP01ntibXtdvRr0IXW0CRGj9AI0Sfk8g+X2ah5JUdZ5whz0xxgMWLNv8WlIVRPj529VCdIIcuE9677ZdjOPaEKdFtJX5dx9RNoOgpQ9JDNQuQP+QO071AK/R0mVwPiDy5Da7cIuf2Zh/Br/zWNlh1r2jQbkRxzjtui/g/aVFg4V5Hwf5I+WD4C7+1GDto57VF0ScN85/kQHBV2AB5t+Fsgki5J29hWxtJyFQinrvVl1zcIXWUSYTWrmyZRb6xk2OjaSBA1vta4+Dyxn3pPB94MANWKsmOLesi0vstdibxOQH8Ofbnv8RCno002J3HECSxZbvFKgf2OJ/4s6wW93h53X89jOWUuL1VFrUVA7uqPvvqoWs8B8KT3NV2ohTz6rRhEVAQjyOXNyU5gKvrnUwVbYyIQgk9qRIzzZHznJyvR7vl0P2HVwUI1d08sNZGxRwxI3V+zQTvVuJw7yrZ4rQ7omgBJRLAXrL+i+3EK6l8EZkb8n999akRStupdcd0EXpFK6OJBsH2OVkh6S62rXEaSkt6MOKP9sPULKBCCKj5XSiRpqvFQBkV778N6t1wV9+KLwaAjohShAgJy7ynJ9880xVEOgVRdDIRuoH3fea5+kNdHXn9HsgPkQlYePWLBeAlmLSOEvVpNk5eYZC/Ttqzel62e5M3YeI3T98XGr+5uPDLOC4b1lIZuB6ZQbUwBWUjCz9qJ9G/6igRDT/WNIlXNk4tisVTtLe6eE/kezk9y6liWWe9fXmNGG8Llib1xL+VippHcai3b/BVSSKgkFasgYbICRb6U/iKqZCldx+eDruTM2GAMEXSsZpYwNloYbpZ6bedxjjBv0W2UUATGjZJY0rPFVvFR16wns6M95tThPGPFS mlq6dOSZ D6v8o3aLIbjh55VhohJHIolMT/7SJa20ZiqdMhwXZEyuDYVGbw2egJmvq0pcdzJ+gLP6JG/6FIqUpJohmMGfdnf701aKnMvf3VW27Ko7dVQzUbvaw1hxxXiSeD6oDRh+o9SR8iKG0orZig8aW3ydmx14a7zElMQLGMxt4n8C5/Y1GG/qHiICxWwD/6Xg095ttXD4pNjEY+NIyqSX42xX+aFYWIq4DnqORJVVRIjo3xoklj9vqqKI9+kjyRv5MNF+AcXY8MkrnUjkmEzfloXMOURTMzU+SdiabfjWZGl7qci+sg9GLBsfx71tAf6ENwn1MPwnF5jddmt9G+q3jeA1e6UE3pZZg516p3qgqlZgM+dfQqyMRX4I40M/pfM/FuOrLAAH9dGtkE1LfKA64t4Qtq6P+wUzUGMsngS6R8LOq5YlTIwnuKS1GfmKLe91L9LR57cpGnG8t4QQc9jMHK3r73GxPUMJ1NJOz4zz3yKH5z+P/WHIv6c0srmwt5w== 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: Hello Yu Zhao Could you give me your comment? I am waiting for your opinion on the reuse method. I'm planning to resend it as a complete patch with it. Thank you. On Tue, Sep 26, 2023 at 11:15=E2=80=AFPM =EA=B9=80=EC=9E=AC=EC=9B=90 wrote: > > >>>On Mon, Sep 25, 2023 at 10:20?PM Jaewon Kim = wrote: > >>>> > >>>> As the legacy lru provides, the lru_gen needs some trace events for > >>>> debugging. > >>>> > >>>> This commit introduces 2 trace events. > >>>> trace_mm_vmscan_lru_gen_scan > >>>> trace_mm_vmscan_lru_gen_evict > >>>> > >>>> Each event is similar to the following legacy events. > >>>> trace_mm_vmscan_lru_isolate, > >>>> trace_mm_vmscan_lru_shrink_[in]active > >>> > >>>We should just reuse trace_mm_vmscan_lru_isolate and > >>>trace_mm_vmscan_lru_shrink_inactive instead of adding new tracepoints. > >>> > >>>To reuse trace_mm_vmscan_lru_isolate, we'd just need to append two new > >>>names to LRU_NAMES. > >>> > >>>The naming of trace_mm_vmscan_lru_shrink_inactive might seem confusing > >>>but it's how MGLRU maintains the compatibility, e.g., the existing > >>>active/inactive counters in /proc/vmstat. > >> > >> > >>Hello > >> > >>Actually I had tried to reuse them. But some value was not that compati= ble. > >>Let me try that way again. > >> > >>> > > > >Hello Yu Zhao > > > >Could you look into what I tried below? I reused the legacy trace events= as you recommened. > > > >For the nr_scanned for trace_mm_vmscan_lru_shrink_inactive, I just used = the scanned returned from isolate_folios. > >I thought this is right as scan_folios also uses its isolated. > > __count_vm_events(PGSCAN_ANON + type, isolated); > >But I guess the scanned in scan_folios is actually the one used in shrin= k_inactive_list > > please ignore nr_scanned thing above I just misread the code. > > This is an example, I think it works well. > > mm_vmscan_lru_isolate: isolate_mode=3D0 classzone=3D2 order=3D0 nr_reque= sted=3D4096 nr_scanned=3D64 nr_skipped=3D0 nr_taken=3D64 lru=3Dinactive_fil= e > mm_vmscan_lru_shrink_inactive: nid=3D0 nr_scanned=3D64 nr_reclaimed=3D63= nr_dirty=3D0 nr_writeback=3D0 nr_congested=3D0 nr_immediate=3D0 nr_activat= e_anon=3D0 nr_activate_file=3D1 nr_ref_keep=3D0 nr_unmap_fail=3D0 priority= =3D2 flags=3DRECLAIM_WB_FILE|RECLAIM_WB_ASYNC > > > > >I tested this on both 0 and 7 of /sys/kernel/mm/lru_gen/enabled > > > > > >diff --git a/mm/vmscan.c b/mm/vmscan.c > >index a4e44f1c97c1..b61a0156559c 100644 > >--- a/mm/vmscan.c > >+++ b/mm/vmscan.c > >@@ -4328,6 +4328,7 @@ static int scan_folios(struct lruvec *lruvec, stru= ct scan_control *sc, > > int sorted =3D 0; > > int scanned =3D 0; > > int isolated =3D 0; > >+ int skipped =3D 0; > > int remaining =3D MAX_LRU_BATCH; > > struct lru_gen_folio *lrugen =3D &lruvec->lrugen; > > struct mem_cgroup *memcg =3D lruvec_memcg(lruvec); > >@@ -4341,7 +4342,7 @@ static int scan_folios(struct lruvec *lruvec, stru= ct scan_control *sc, > > > > for (i =3D MAX_NR_ZONES; i > 0; i--) { > > LIST_HEAD(moved); > >- int skipped =3D 0; > >+ int skipped_zone =3D 0; > > int zone =3D (sc->reclaim_idx + i) % MAX_NR_ZONES; > > struct list_head *head =3D &lrugen->folios[gen][type][zo= ne]; > > > >@@ -4363,16 +4364,17 @@ static int scan_folios(struct lruvec *lruvec, st= ruct scan_control *sc, > > isolated +=3D delta; > > } else { > > list_move(&folio->lru, &moved); > >- skipped +=3D delta; > >+ skipped_zone +=3D delta; > > } > > > >- if (!--remaining || max(isolated, skipped) >=3D = MIN_LRU_BATCH) > >+ if (!--remaining || max(isolated, skipped_zone) = >=3D MIN_LRU_BATCH) > > break; > > } > > > >- if (skipped) { > >+ if (skipped_zone) { > > list_splice(&moved, head); > >- __count_zid_vm_events(PGSCAN_SKIP, zone, skipped= ); > >+ __count_zid_vm_events(PGSCAN_SKIP, zone, skipped= _zone); > >+ skipped +=3D skipped_zone; > > } > > > > if (!remaining || isolated >=3D MIN_LRU_BATCH) > >@@ -4387,6 +4389,9 @@ static int scan_folios(struct lruvec *lruvec, stru= ct scan_control *sc, > > __count_memcg_events(memcg, item, isolated); > > __count_memcg_events(memcg, PGREFILL, sorted); > > __count_vm_events(PGSCAN_ANON + type, isolated); > >+ trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, MAX_LRU_= BATCH, > >+ scanned, skipped, isolated, > >+ type ? LRU_INACTIVE_FILE : LRU_INACT= IVE_ANON); > > > > /* > > * There might not be eligible folios due to reclaim_idx. Check = the > >@@ -4517,6 +4522,9 @@ static int evict_folios(struct lruvec *lruvec, str= uct scan_control *sc, int swap > > retry: > > reclaimed =3D shrink_folio_list(&list, pgdat, sc, &stat, false); > > sc->nr_reclaimed +=3D reclaimed; > >+ trace_mm_vmscan_lru_shrink_inactive(pgdat->node_id, > >+ scanned, reclaimed, &stat, sc->priority, > >+ type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON); > > > > list_for_each_entry_safe_reverse(folio, next, &list, lru) { > > if (!folio_evictable(folio)) { > >