| Message ID | 181C946095F0252B+7cc60eca-1abf-4502-aad3-ffd8ef89d910@ex.bilibili.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | delayacct: add memory reclaim delay in get_page_from_freelist | expand |
On Wed, 20 Sep 2023 17:38:49 +0800 liwenyu <wenyuli@ex.bilibili.com> wrote: > The current memory reclaim delay statistics only count the direct memory > reclaim of the task in do_try_to_free_pages(). In systems with NUMA > open, some tasks occasionally experience slower response times, but the > total count of reclaim does not increase, using ftrace can show that > node_reclaim has occurred. > > The memory reclaim occurring in get_page_from_freelist() is also due to > heavy memory load. To get the impact of tasks in memory reclaim, this > patch adds the statistics of the memory reclaim delay statistics for > __node_reclaim(). Please review Documentation/accounting/delay-accounting.rst, see if there is some change we can make to reflect this patch. Your email client is wordwrapping the patches - please check that for next time.
> On Wed, 20 Sep 2023 17:38:49 +0800 liwenyu <wenyuli@ex.bilibili.com> wrote: > >> The current memory reclaim delay statistics only count the direct memory >> reclaim of the task in do_try_to_free_pages(). In systems with NUMA >> open, some tasks occasionally experience slower response times, but the >> total count of reclaim does not increase, using ftrace can show that >> node_reclaim has occurred. >> >> The memory reclaim occurring in get_page_from_freelist() is also due to >> heavy memory load. To get the impact of tasks in memory reclaim, this >> patch adds the statistics of the memory reclaim delay statistics for >> __node_reclaim(). > > Please review Documentation/accounting/delay-accounting.rst, see if > there is some change we can make to reflect this patch. > > Your email client is wordwrapping the patches - please check that for > next time. > There is no need to change the Documentation/accounting/delay-accounting.rst, because this patch is only an expansion of memory reclaim delayacct. Thanks!
diff --git a/mm/vmscan.c b/mm/vmscan.c index 6f13394b112e..88be3dedc584 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -8026,6 +8026,7 @@ static int __node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned in cond_resched(); psi_memstall_enter(&pflags); + delayacct_freepages_start(); fs_reclaim_acquire(sc.gfp_mask); /*
The current memory reclaim delay statistics only count the direct memory reclaim of the task in do_try_to_free_pages(). In systems with NUMA open, some tasks occasionally experience slower response times, but the total count of reclaim does not increase, using ftrace can show that node_reclaim has occurred. The memory reclaim occurring in get_page_from_freelist() is also due to heavy memory load. To get the impact of tasks in memory reclaim, this patch adds the statistics of the memory reclaim delay statistics for __node_reclaim(). Signed-off-by: Wen Yu Li <wenyuli@ex.bilibili.com> --- mm/vmscan.c | 2 ++ 1 file changed, 2 insertions(+) * We need to be able to allocate from the reserves for RECLAIM_UNMAP @@ -8048,6 +8049,7 @@ static int __node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned in memalloc_noreclaim_restore(noreclaim_flag); fs_reclaim_release(sc.gfp_mask); psi_memstall_leave(&pflags); + delayacct_freepages_end(); trace_mm_vmscan_node_reclaim_end(sc.nr_reclaimed);