From: Dave Hansen <dave@sr71.net>
To: Johannes Weiner <hannes@cmpxchg.org>,
Dave Hansen <dave.hansen@intel.com>
Cc: Michal Hocko <mhocko@suse.cz>, Hugh Dickins <hughd@google.com>,
Tejun Heo <tj@kernel.org>, Linux-MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Vladimir Davydov <vdavydov@parallels.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: regression caused by cgroups optimization in 3.17-rc2
Date: Tue, 09 Sep 2014 11:23:14 -0700 [thread overview]
Message-ID: <540F4592.9030408@sr71.net> (raw)
In-Reply-To: <20140909145044.GA16027@cmpxchg.org>
On 09/09/2014 07:50 AM, Johannes Weiner wrote:
> The mctz->lock is only taken when there is, or has been, soft limit
> excess. However, the soft limit defaults to infinity, so unless you
> set it explicitly on the root level, I can't see how this could be
> mctz->lock contention.
>
> It's more plausible that this is the res_counter lock for testing soft
> limit excess - for me, both these locks get inlined into check_events,
> could you please double check you got the right lock?
I got the wrong lock. Here's how it looks after mainline, plus your free_pages_and_swap_cache() patch:
Samples: 2M of event 'cycles', Event count (approx.): 51647128377
+ 60.60% 1.33% page_fault2_processes [.] testcase a??
+ 59.14% 0.41% [kernel] [k] page_fault a??
+ 58.72% 0.01% [kernel] [k] do_page_fault a??
+ 58.70% 0.08% [kernel] [k] __do_page_fault a??
+ 58.50% 0.29% [kernel] [k] handle_mm_fault a??
+ 40.14% 0.28% [kernel] [k] do_cow_fault a??
- 34.56% 34.56% [kernel] [k] _raw_spin_lock a??
- _raw_spin_lock a??
- 78.11% __res_counter_charge a??
res_counter_charge a??
try_charge a??
- mem_cgroup_try_charge a??
+ 99.99% do_cow_fault a??
- 10.30% res_counter_uncharge_until a??
res_counter_uncharge a??
uncharge_batch a??
uncharge_list a??
mem_cgroup_uncharge_list a??
release_pages a??
+ 4.75% free_pcppages_bulk a??
+ 3.65% do_cow_fault a??
+ 2.24% get_page_from_freelist a??
> You also said that this cost hasn't been there before, but I do see
> that trace in both v3.16 and v3.17-rc3 with roughly the same impact
> (although my machines show less contention than yours). Could you
> please double check that this is in fact a regression independent of
> 05b843012335 ("mm: memcontrol: use root_mem_cgroup res_counter")?
Here's the same workload on the same machine with only Johannes' revert applied:
- 35.92% 35.92% [kernel] [k] _raw_spin_lock a??
- _raw_spin_lock a??
- 49.09% get_page_from_freelist a??
- __alloc_pages_nodemask a??
+ 99.90% alloc_pages_vma a??
- 43.67% free_pcppages_bulk a??
- 100.00% free_hot_cold_page a??
+ 99.93% free_hot_cold_page_list a??
- 7.08% do_cow_fault a??
handle_mm_fault a??
__do_page_fault a??
do_page_fault a??
page_fault a??
testcase a??
So I think it's probably part of the same regression.
--
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: Dave Hansen <dave@sr71.net>
To: Johannes Weiner <hannes@cmpxchg.org>,
Dave Hansen <dave.hansen@intel.com>
Cc: Michal Hocko <mhocko@suse.cz>, Hugh Dickins <hughd@google.com>,
Tejun Heo <tj@kernel.org>, Linux-MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Vladimir Davydov <vdavydov@parallels.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: regression caused by cgroups optimization in 3.17-rc2
Date: Tue, 09 Sep 2014 11:23:14 -0700 [thread overview]
Message-ID: <540F4592.9030408@sr71.net> (raw)
In-Reply-To: <20140909145044.GA16027@cmpxchg.org>
On 09/09/2014 07:50 AM, Johannes Weiner wrote:
> The mctz->lock is only taken when there is, or has been, soft limit
> excess. However, the soft limit defaults to infinity, so unless you
> set it explicitly on the root level, I can't see how this could be
> mctz->lock contention.
>
> It's more plausible that this is the res_counter lock for testing soft
> limit excess - for me, both these locks get inlined into check_events,
> could you please double check you got the right lock?
I got the wrong lock. Here's how it looks after mainline, plus your free_pages_and_swap_cache() patch:
Samples: 2M of event 'cycles', Event count (approx.): 51647128377
+ 60.60% 1.33% page_fault2_processes [.] testcase ▒
+ 59.14% 0.41% [kernel] [k] page_fault ◆
+ 58.72% 0.01% [kernel] [k] do_page_fault ▒
+ 58.70% 0.08% [kernel] [k] __do_page_fault ▒
+ 58.50% 0.29% [kernel] [k] handle_mm_fault ▒
+ 40.14% 0.28% [kernel] [k] do_cow_fault ▒
- 34.56% 34.56% [kernel] [k] _raw_spin_lock ▒
- _raw_spin_lock ▒
- 78.11% __res_counter_charge ▒
res_counter_charge ▒
try_charge ▒
- mem_cgroup_try_charge ▒
+ 99.99% do_cow_fault ▒
- 10.30% res_counter_uncharge_until ▒
res_counter_uncharge ▒
uncharge_batch ▒
uncharge_list ▒
mem_cgroup_uncharge_list ▒
release_pages ▒
+ 4.75% free_pcppages_bulk ▒
+ 3.65% do_cow_fault ▒
+ 2.24% get_page_from_freelist ▒
> You also said that this cost hasn't been there before, but I do see
> that trace in both v3.16 and v3.17-rc3 with roughly the same impact
> (although my machines show less contention than yours). Could you
> please double check that this is in fact a regression independent of
> 05b843012335 ("mm: memcontrol: use root_mem_cgroup res_counter")?
Here's the same workload on the same machine with only Johannes' revert applied:
- 35.92% 35.92% [kernel] [k] _raw_spin_lock ▒
- _raw_spin_lock ▒
- 49.09% get_page_from_freelist ▒
- __alloc_pages_nodemask ▒
+ 99.90% alloc_pages_vma ▒
- 43.67% free_pcppages_bulk ▒
- 100.00% free_hot_cold_page ▒
+ 99.93% free_hot_cold_page_list ▒
- 7.08% do_cow_fault ▒
handle_mm_fault ▒
__do_page_fault ▒
do_page_fault ▒
page_fault ▒
testcase ▒
So I think it's probably part of the same regression.
next prev parent reply other threads:[~2014-09-09 18:23 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-02 19:05 regression caused by cgroups optimization in 3.17-rc2 Dave Hansen
2014-09-02 19:05 ` Dave Hansen
2014-09-02 20:18 ` Dave Hansen
2014-09-02 20:57 ` Dave Hansen
2014-09-02 20:57 ` Dave Hansen
2014-09-04 14:27 ` Michal Hocko
2014-09-04 14:27 ` Michal Hocko
2014-09-04 20:27 ` Dave Hansen
2014-09-04 20:27 ` Dave Hansen
2014-09-04 22:53 ` Dave Hansen
2014-09-04 22:53 ` Dave Hansen
2014-09-05 9:28 ` Michal Hocko
2014-09-05 9:28 ` Michal Hocko
2014-09-05 9:25 ` Michal Hocko
2014-09-05 9:25 ` Michal Hocko
2014-09-05 14:47 ` Johannes Weiner
2014-09-05 14:47 ` Johannes Weiner
2014-09-05 15:39 ` Michal Hocko
2014-09-05 15:39 ` Michal Hocko
2014-09-10 16:29 ` Michal Hocko
2014-09-10 16:29 ` Michal Hocko
2014-09-10 16:57 ` Dave Hansen
2014-09-10 16:57 ` Dave Hansen
2014-09-10 17:05 ` Michal Hocko
2014-09-10 17:05 ` Michal Hocko
2014-09-05 12:35 ` Johannes Weiner
2014-09-05 12:35 ` Johannes Weiner
2014-09-08 15:47 ` Dave Hansen
2014-09-08 15:47 ` Dave Hansen
2014-09-09 14:50 ` Johannes Weiner
2014-09-09 14:50 ` Johannes Weiner
2014-09-09 18:23 ` Dave Hansen [this message]
2014-09-09 18:23 ` Dave Hansen
2014-09-02 22:18 ` Johannes Weiner
2014-09-02 22:18 ` Johannes Weiner
2014-09-02 22:36 ` Dave Hansen
2014-09-03 0:10 ` Johannes Weiner
2014-09-03 0:10 ` Johannes Weiner
2014-09-03 0:20 ` Linus Torvalds
2014-09-03 0:20 ` Linus Torvalds
2014-09-03 1:33 ` Johannes Weiner
2014-09-03 1:33 ` Johannes Weiner
2014-09-03 3:15 ` Dave Hansen
2014-09-03 3:15 ` Dave Hansen
2014-09-03 0:30 ` Dave Hansen
2014-09-03 0:30 ` Dave Hansen
2014-09-04 15:08 ` Johannes Weiner
2014-09-04 15:08 ` Johannes Weiner
2014-09-04 20:50 ` Dave Hansen
2014-09-04 20:50 ` Dave Hansen
2014-09-05 8:04 ` Michal Hocko
2014-09-05 8:04 ` Michal Hocko
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=540F4592.9030408@sr71.net \
--to=dave@sr71.net \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vdavydov@parallels.com \
/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.