From: Johannes Weiner <hannes@cmpxchg.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.cz>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH 1/2] mm: Avoid full RCU lookup of memcg for statistics updates
Date: Wed, 23 Jul 2014 07:44:49 -0400 [thread overview]
Message-ID: <20140723114449.GE1725@cmpxchg.org> (raw)
In-Reply-To: <1406114656-16350-2-git-send-email-mgorman@suse.de>
On Wed, Jul 23, 2014 at 12:24:15PM +0100, Mel Gorman wrote:
> When updating memcg VM statistics like PGFAULT we take the rcu read
> lock and lookup the memcg. For statistic updates this is overkill
> when the process may not belong to a memcg. This patch adds a light
> check to check if a memcg potentially exists. It's race-prone in that
> some VM stats may be missed when a process first joins a memcg but
> that is not serious enough to justify a constant performance penalty.
Tasks always belong to a memcg, the root group per default. There
isn't really any accounting that could be omitted.
> The exact impact of this is difficult to quantify because it's timing
> sensitive, workload sensitive and sensitive to the RCU options set. However,
> broadly speaking there should be less interference due to page fault
> activity in both the number of RCU grace periods and their age.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> ---
> include/linux/memcontrol.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index eb65d29..76fa97d 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -220,6 +220,14 @@ static inline void mem_cgroup_count_vm_event(struct mm_struct *mm,
> {
> if (mem_cgroup_disabled())
> return;
> + /*
> + * For statistic updates it's overkill to take the RCU lock and do
> + * a fully safe lookup of an associated memcg. Do a simple check
> + * first. At worst, we miss a few stat updates when a process is
> + * moved to a memcg for the first time.
> + */
> + if (!rcu_access_pointer(mm->owner))
> + return;
mm->owner is set when the mm is first initialized, it's only NULL
during race conditions on exit.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.cz>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH 1/2] mm: Avoid full RCU lookup of memcg for statistics updates
Date: Wed, 23 Jul 2014 07:44:49 -0400 [thread overview]
Message-ID: <20140723114449.GE1725@cmpxchg.org> (raw)
In-Reply-To: <1406114656-16350-2-git-send-email-mgorman@suse.de>
On Wed, Jul 23, 2014 at 12:24:15PM +0100, Mel Gorman wrote:
> When updating memcg VM statistics like PGFAULT we take the rcu read
> lock and lookup the memcg. For statistic updates this is overkill
> when the process may not belong to a memcg. This patch adds a light
> check to check if a memcg potentially exists. It's race-prone in that
> some VM stats may be missed when a process first joins a memcg but
> that is not serious enough to justify a constant performance penalty.
Tasks always belong to a memcg, the root group per default. There
isn't really any accounting that could be omitted.
> The exact impact of this is difficult to quantify because it's timing
> sensitive, workload sensitive and sensitive to the RCU options set. However,
> broadly speaking there should be less interference due to page fault
> activity in both the number of RCU grace periods and their age.
>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> ---
> include/linux/memcontrol.h | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index eb65d29..76fa97d 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -220,6 +220,14 @@ static inline void mem_cgroup_count_vm_event(struct mm_struct *mm,
> {
> if (mem_cgroup_disabled())
> return;
> + /*
> + * For statistic updates it's overkill to take the RCU lock and do
> + * a fully safe lookup of an associated memcg. Do a simple check
> + * first. At worst, we miss a few stat updates when a process is
> + * moved to a memcg for the first time.
> + */
> + if (!rcu_access_pointer(mm->owner))
> + return;
mm->owner is set when the mm is first initialized, it's only NULL
during race conditions on exit.
next prev parent reply other threads:[~2014-07-23 11:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-23 11:24 [PATCH 0/2] Avoid unnecessary overhead in fault paths due to memcg and rss stats Mel Gorman
2014-07-23 11:24 ` Mel Gorman
2014-07-23 11:24 ` [PATCH 1/2] mm: Avoid full RCU lookup of memcg for statistics updates Mel Gorman
2014-07-23 11:24 ` Mel Gorman
2014-07-23 11:44 ` Johannes Weiner [this message]
2014-07-23 11:44 ` Johannes Weiner
2014-07-23 12:58 ` Mel Gorman
2014-07-23 12:58 ` Mel Gorman
2014-07-23 11:24 ` [PATCH 2/2] mm: Move RSS stat event count synchronisation out of the fast path Mel Gorman
2014-07-23 11:24 ` Mel Gorman
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=20140723114449.GE1725@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.