Re: [PATCH 1/2] mm, memcg: Try charging a page before setting page up to date

From: Johannes Weiner
Date: Wed May 20 2015 - 11:30:00 EST

On Wed, May 20, 2015 at 01:50:44PM +0100, Mel Gorman wrote:
> Historically memcg overhead was high even if memcg was unused. This has
> improved a lot but it still showed up in a profile summary as being a
> problem.
>
> /usr/src/linux-4.0-vanilla/mm/memcontrol.c 6.6441 395842
> mem_cgroup_try_charge 2.950% 175781
> __mem_cgroup_count_vm_event 1.431% 85239
> mem_cgroup_page_lruvec 0.456% 27156
> mem_cgroup_commit_charge 0.392% 23342
> uncharge_list 0.323% 19256
> mem_cgroup_update_lru_size 0.278% 16538
> memcg_check_events 0.216% 12858
> mem_cgroup_charge_statistics.isra.22 0.188% 11172
> try_charge 0.150% 8928
> commit_charge 0.141% 8388
> get_mem_cgroup_from_mm 0.121% 7184
>
> That is showing that 6.64% of system CPU cycles were in memcontrol.c and
> dominated by mem_cgroup_try_charge. The annotation shows that the bulk of
> the cost was checking PageSwapCache which is expected to be cache hot but is
> very expensive. The problem appears to be that __SetPageUptodate is called
> just before the check which is a write barrier. It is required to make sure
> struct page and page data is written before the PTE is updated and the data
> visible to userspace. memcg charging does not require or need the barrier
> but gets unfairly hit with the cost so this patch attempts the charging
> before the barrier. Aside from the accidental cost to memcg there is the
> added benefit that the barrier is avoided if the page cannot be charged.
> When applied the relevant profile summary is as follows.
>
> /usr/src/linux-4.0-chargefirst-v2r1/mm/memcontrol.c 3.7907 223277
> __mem_cgroup_count_vm_event 1.143% 67312

Out of curiosity, I'm still consistently reading this function at
around 0.7%. Are you profiling this single-threadedly or for the
entire run? For profiling 80 single-threaded iterations, I get:

+ 1.31% 0.59% pft [kernel.kallsyms] [k] mem_cgroup_try_charge
+ 0.72% 0.44% pft [kernel.kallsyms] [k] mem_cgroup_commit_charge
+ 0.67% 0.67% pft [kernel.kallsyms] [k] __mem_cgroup_count_vm_event
+ 0.57% 0.57% pft [kernel.kallsyms] [k] get_mem_cgroup_from_mm
+ 0.32% 0.01% pft [kernel.kallsyms] [k] mem_cgroup_uncharge_list
+ 0.42% 0.42% pft [kernel.kallsyms] [k] mem_cgroup_page_lruvec
+ 0.31% 0.30% pft [kernel.kallsyms] [k] uncharge_list
+ 0.28% 0.28% pft [kernel.kallsyms] [k] try_charge
+ 0.21% 0.21% pft [kernel.kallsyms] [k] mem_cgroup_charge_statistics.isra.26
+ 0.20% 0.20% pft [kernel.kallsyms] [k] mem_cgroup_update_lru_size
+ 0.13% 0.13% pft [kernel.kallsyms] [k] commit_charge
+ 0.10% 0.09% pft [kernel.kallsyms] [k] memcg_check_events

Adding up the recursive profile (first column) for the entry functions
(try_charge, commit, pgfault accounting, uncharge), this yields 3.02%.

> mem_cgroup_page_lruvec 0.465% 27403
> mem_cgroup_commit_charge 0.381% 22452
> uncharge_list 0.332% 19543
> mem_cgroup_update_lru_size 0.284% 16704
> get_mem_cgroup_from_mm 0.271% 15952
> mem_cgroup_try_charge 0.237% 13982
> memcg_check_events 0.222% 13058
> mem_cgroup_charge_statistics.isra.22 0.185% 10920
> commit_charge 0.140% 8235
> try_charge 0.131% 7716
>
> That brings the overhead down to 3.79% and leaves the memcg fault accounting
> to the root cgroup but it's an improvement. The difference in headline
> performance of the page fault microbench is marginal as memcg is such a
> small component of it.
>
> pft faults
> 4.0.0 4.0.0
> vanilla chargefirst
> Hmean faults/cpu-1 1443258.1051 ( 0.00%) 1509075.7561 ( 4.56%)
> Hmean faults/cpu-3 1340385.9270 ( 0.00%) 1339160.7113 ( -0.09%)
> Hmean faults/cpu-5 875599.0222 ( 0.00%) 874174.1255 ( -0.16%)
> Hmean faults/cpu-7 601146.6726 ( 0.00%) 601370.9977 ( 0.04%)
> Hmean faults/cpu-8 510728.2754 ( 0.00%) 510598.8214 ( -0.03%)
> Hmean faults/sec-1 1432084.7845 ( 0.00%) 1497935.5274 ( 4.60%)
> Hmean faults/sec-3 3943818.1437 ( 0.00%) 3941920.1520 ( -0.05%)
> Hmean faults/sec-5 3877573.5867 ( 0.00%) 3869385.7553 ( -0.21%)
> Hmean faults/sec-7 3991832.0418 ( 0.00%) 3992181.4189 ( 0.01%)
> Hmean faults/sec-8 3987189.8167 ( 0.00%) 3986452.2204 ( -0.02%)
>
> It's only visible at single threaded. The overhead is there for higher
> threads but other factors dominate.
>
> Signed-off-by: Mel Gorman <mgorman@xxxxxxx>

Awesome analysis, thank you Mel.

Acked-by: Johannes Weiner <hannes@xxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/