From: Vlastimil Babka <vbabka@suse.cz>
To: jaewon31.kim@samsung.com, "sj@kernel.org" <sj@kernel.org>,
"minchan@kernel.org" <minchan@kernel.org>,
"kaleshsingh@google.com" <kaleshsingh@google.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jaewon31.kim@gmail.com" <jaewon31.kim@gmail.com>
Subject: Re: [PATCH] vmscan: add a vmscan event for reclaim_pages
Date: Fri, 11 Oct 2024 10:55:50 +0200 [thread overview]
Message-ID: <dd7e07ba-acaf-4f93-93e0-ec2d98a4da55@suse.cz> (raw)
In-Reply-To: <20241011082539epcms1p6039313672abedf63d5368a3eae87bad5@epcms1p6>
On 10/11/24 10:25 AM, Jaewon Kim wrote:
> Hi
>
> Thank you for your coment. Yes if it is allowed, I can do that way. When
> I checked, the following functions should do the memset().
>
> reclaim_clean_pages_from_list
> shrink_inactive_list
> reclaim_folio_list
> evict_folios
>
> Actually I was planning to move trace_mm_vmscan_reclaim_pages into
> reclaim_folio_list so that we don't have to sum up and we may be able
> to print node number, too. As we will see log for each node, if we'd
> like to know the sum, that would be the post parser's job.
>
> Option 1. No change on memset, but print on each node.
> mm_vmscan_reclaim_pages: nid=0 nr_scanned=112 nr_reclaimed=112 nr_dirty=0 nr_writeback=0 nr_congested=0 nr_immediate=0 nr_activate_anon=0 nr_activate_file=0 nr_ref_keep=0 nr_unmap_fail=0
> mm_vmscan_reclaim_pages: nid=1 ...
> mm_vmscan_reclaim_pages: nid=2 ...
I see. Note it processes a list that might be from multiple nodes and
will group consecutive pages from the same node, but if pages come from
random nodes, the nodes will repeat and there might be many trace
events, each for few pages only.
Guess it depends on the workload if it has its pages from the same node.
Maybe you can try and see how noisy it is in practice?
> Option 2. Change on memset, but we don't care the stat from each node.
> mm_vmscan_reclaim_pages: nr_scanned=35 nr_reclaimed=35 nr_dirty=0 nr_writeback=0 nr_congested=0 nr_immediate=0 nr_activate_anon=0 nr_activate_file=0 nr_ref_keep=0 nr_unmap_fail=0
>
> Would you give me you preference between the two options?
>
> Thank you
> Jaewon Kim
>
>>
>> AFAICS shrink_folio_list() only cares about these fields:
>>
>> pgactivate = stat->nr_activate[0] + stat->nr_activate[1];
>>
>> in order to do
>>
>> count_vm_events(PGACTIVATE, pgactivate);
>>
>> Which could be adjusted to deal with accumulating stat - i.e. take an
>> initial sum of the fields in stat and subtract from the final sum to get
>> the delta.
>>
>>> unsigned long reclaim_pages(struct list_head *folio_list)
>>> {
>>> int nid;
>>> + unsigned int nr_scanned = 0;
>>> unsigned int nr_reclaimed = 0;
>>> LIST_HEAD(node_folio_list);
>>> unsigned int noreclaim_flag;
>>> + struct reclaim_stat stat_total, stat_one;
>>>
>>> if (list_empty(folio_list))
>>> return nr_reclaimed;
>>>
>>> + memset(&stat_total, 0, sizeof(stat_total));
>>> noreclaim_flag = memalloc_noreclaim_save();
>>>
>>> nid = folio_nid(lru_to_folio(folio_list));
>>> @@ -2168,14 +2192,20 @@ unsigned long reclaim_pages(struct list_head *folio_list)
>>> if (nid == folio_nid(folio)) {
>>> folio_clear_active(folio);
>>> list_move(&folio->lru, &node_folio_list);
>>> + nr_scanned += folio_nr_pages(folio);
>>> continue;
>>> }
>>>
>>> - nr_reclaimed += reclaim_folio_list(&node_folio_list, NODE_DATA(nid));
>>> + nr_reclaimed += reclaim_folio_list(&node_folio_list,
>>> + NODE_DATA(nid), &stat_one);
>>> + reclaim_stat_add(&stat_one, &stat_total);
>>> nid = folio_nid(lru_to_folio(folio_list));
>>> } while (!list_empty(folio_list));
>>>
>>> - nr_reclaimed += reclaim_folio_list(&node_folio_list, NODE_DATA(nid));
>>> + nr_reclaimed += reclaim_folio_list(&node_folio_list, NODE_DATA(nid),
>>> + &stat_one);
>>> + reclaim_stat_add(&stat_one, &stat_total);
>>> + trace_mm_vmscan_reclaim_pages(nr_scanned, nr_reclaimed, &stat_total);
>>>
>>> memalloc_noreclaim_restore(noreclaim_flag);
>>>
next prev parent reply other threads:[~2024-10-11 8:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20241009093133epcas1p39b770ebcc6d2d78cad2f9a522bc6f179@epcas1p3.samsung.com>
2024-10-09 9:31 ` Jaewon Kim
2024-10-09 20:49 ` Andrew Morton
2024-10-10 8:28 ` Vlastimil Babka
[not found] ` <CGME20241009093133epcas1p39b770ebcc6d2d78cad2f9a522bc6f179@epcms1p1>
2024-10-11 8:22 ` 김재원
[not found] ` <CGME20241009093133epcas1p39b770ebcc6d2d78cad2f9a522bc6f179@epcms1p6>
2024-10-09 23:53 ` Jaewon Kim
2024-10-11 8:25 ` Jaewon Kim
2024-10-11 8:55 ` Vlastimil Babka [this message]
[not found] ` <CGME20241009093133epcas1p39b770ebcc6d2d78cad2f9a522bc6f179@epcms1p4>
2024-10-11 11:39 ` Jaewon Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dd7e07ba-acaf-4f93-93e0-ec2d98a4da55@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=jaewon31.kim@gmail.com \
--cc=jaewon31.kim@samsung.com \
--cc=kaleshsingh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=sj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox