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.
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@xxxxxxx>
---
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;
__mem_cgroup_count_vm_event(mm, idx);
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
--
1.8.4.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>