Hide Forgot
Description of problem: Bad scalability with memory cgroups. Version-Release number of selected component (if applicable): 2.6.32-131.12.1 How reproducible: run a program that allocates memory on a 32 cpu system Steps to Reproduce: 1. create a user Memory Cgroup 2. run 32 occurences of program that allocates memory 3. compare time with same program executed outside Memory cgroup or with cgroup_disable=memory Actual results: . in cgroup memory: Time for Allocating Buffers : 100.222279 second(s) 75.70% _spin_lock res_counter_uncharge Expected results: . outside cgroup memory: Time for Allocating Buffers : 3.721997 second(s) Additional info: perf profiling shows contention on cgroup spinlock. This has been reworked in recent kernels to coalesce the accounting on cgroup. 2.6.37 kernel does not show the problem of scalability. 75.70% malloc_seq [kernel.kallsyms] [k] _s | --- _spin_lock | |--52.11%-- res_counter_uncharge | __mem_cgroup_uncharge_common | mem_cgroup_uncharge_page | page_remove_rmap | unmap_vmas | exit_mmap | mmput | | | |--100.00%-- exit_mm | | do_exit | | do_group_exit | | sys_exit_group | | system_call_fastpath | --0.00%-- [...] | |--47.86%-- res_counter_charge
@xavier Is this the same issue as reported from Bull via myself at: https://bugzilla.redhat.com/show_bug.cgi?id=717803 ?
Yes,....Sorry I missed it was already opened as a Bugzilla.
No problem. I'll closed this BZ as a DUPLICATE of the other. Can I ask you to please add the above information (and any additional data) as a new comment on the other BZ? (so that it is seen to come from an @bull.net address rather than an internal @redhat.com address). *** This bug has been marked as a duplicate of bug 717803 ***