Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754764AbbETQP1 (ORCPT ); Wed, 20 May 2015 12:15:27 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33183 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754020AbbETQPZ (ORCPT ); Wed, 20 May 2015 12:15:25 -0400 Date: Wed, 20 May 2015 17:15:21 +0100 From: Mel Gorman To: Johannes Weiner Cc: Michal Hocko , Andrew Morton , Tejun Heo , Linux-CGroups , Linux-MM , LKML Subject: Re: [PATCH 1/2] mm, memcg: Try charging a page before setting page up to date Message-ID: <20150520161520.GR2462@suse.de> References: <1432126245-10908-1-git-send-email-mgorman@suse.de> <1432126245-10908-2-git-send-email-mgorman@suse.de> <20150520152923.GA2874@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20150520152923.GA2874@cmpxchg.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3192 Lines: 51 On Wed, May 20, 2015 at 11:29:23AM -0400, Johannes Weiner wrote: > 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: > Single-threaded. The mmtests benchmark in question supports gathering one profile per thread count so it's just the 1 thread profile I included in the changelog. The CPU in question is a i7-3770 -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/