Re: regression caused by cgroups optimization in 3.17-rc2
From: Dave Hansen
Date: Tue Sep 02 2014 - 20:30:44 EST
On 09/02/2014 05:10 PM, Johannes Weiner wrote:
> On Tue, Sep 02, 2014 at 03:36:29PM -0700, Dave Hansen wrote:
>> On 09/02/2014 03:18 PM, Johannes Weiner wrote:
>>> Accounting new pages is buffered through per-cpu caches, but taking
>>> them off the counters on free is not, so I'm guessing that above a
>>> certain allocation rate the cost of locking and changing the counters
>>> takes over. Is there a chance you could profile this to see if locks
>>> and res_counter-related operations show up?
>> It looks pretty much the same, although it might have equalized the
>> charge and uncharge sides a bit. Full 'perf top' output attached.
> That looks like a partial profile, where did the page allocator, page
> zeroing etc. go? Because the distribution among these listed symbols
> doesn't seem all that crazy:
Perf was only outputting the top 20 functions. Believe it or not, page
zeroing and the rest of the allocator path wasn't even in the path of
the top 20 functions because there is so much lock contention.
Here's a longer run of 'perf top' along with the top 100 functions:
you can at least see copy_page_rep in there.
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/