From: Tim Chen <tim.c.chen@linux.intel.com>
To: Chen Taotao <chentt10@chinatelecom.cn>, akpm@linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] mm: get_mm_counter() get the total memory usage of the process
Date: Tue, 09 Apr 2024 19:17:08 -0700 [thread overview]
Message-ID: <19a3c2890b18ce230a9e147c0eeee27caf0c4137.camel@linux.intel.com> (raw)
In-Reply-To: <20240322151139.7417-1-chentt10@chinatelecom.cn>
On Fri, 2024-03-22 at 23:11 +0800, Chen Taotao wrote:
> Currently, the get_mm_counter() function returns only the value of
> the process memory counter percpu_counter ->count record, ignoring
> the memory usage count maintained by each CPU in the
> percpu_counter->counters array, which leads to an error in obtaining
> the memory usage count of a process, especially when there are many
> CPU cores. counts, especially when there are many CPU cores.
>
> It is now possible to have get_mm_counter() get the memory count of a
> process by adding the memory counts maintained by each cpu, thus getting
> an accurate memory count of the process.
>
> This patch is an unofficial version that simply fixes the above problem,
> as I'm not sure if it makes sense to do so.
Summing up the mm counts maintained in every cpu is expensive,
especially if we are doing the read often. More so
when there are a large number of cores on large servers or
newer CPU with high core counts.
For mm counters,the count in fbc->count is good enough we
don't need to correct fbc->count with the the small counts
update (< percpu_counter_batch) cached in per cpu counts.
So do you have a mm count use case where you really need the precise
count with get_mm_counter?
I do not think we should make the change you suggested.
Tim
>
> Signed-off-by: Chen Taotao <chentt10@chinatelecom.cn>
> ---
> include/linux/mm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index f5a97dec5..5cf6443aa 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2569,7 +2569,7 @@ static inline bool get_user_page_fast_only(unsigned long addr,
> */
> static inline unsigned long get_mm_counter(struct mm_struct *mm, int member)
> {
> - return percpu_counter_read_positive(&mm->rss_stat[member]);
> + return percpu_counter_sum_positive(&mm->rss_stat[member]);
> }
>
> void mm_trace_rss_stat(struct mm_struct *mm, int member);
prev parent reply other threads:[~2024-04-10 2:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 15:11 Chen Taotao
2024-04-10 2:17 ` Tim Chen [this message]
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=19a3c2890b18ce230a9e147c0eeee27caf0c4137.camel@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=chentt10@chinatelecom.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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