From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kamezawa Hiroyuki Subject: Re: [patch] mm, memcg: avoid unnecessary function call when memcg is disabled Date: Wed, 21 Nov 2012 10:02:34 +0900 Message-ID: <50AC282A.4070309@jp.fujitsu.com> References: <20121120134932.055bc192.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20121120134932.055bc192.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Andrew Morton Cc: David Rientjes , Johannes Weiner , Michal Hocko , Hugh Dickins , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org (2012/11/21 6:49), Andrew Morton wrote: > On Mon, 19 Nov 2012 17:44:34 -0800 (PST) > David Rientjes wrote: > >> While profiling numa/core v16 with cgroup_disable=memory on the command >> line, I noticed mem_cgroup_count_vm_event() still showed up as high as >> 0.60% in perftop. >> >> This occurs because the function is called extremely often even when memcg >> is disabled. >> >> To fix this, inline the check for mem_cgroup_disabled() so we avoid the >> unnecessary function call if memcg is disabled. >> >> ... >> >> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h >> --- a/include/linux/memcontrol.h >> +++ b/include/linux/memcontrol.h >> @@ -181,7 +181,14 @@ unsigned long mem_cgroup_soft_limit_reclaim(struct zone *zone, int order, >> gfp_t gfp_mask, >> unsigned long *total_scanned); >> >> -void mem_cgroup_count_vm_event(struct mm_struct *mm, enum vm_event_item idx); >> +void __mem_cgroup_count_vm_event(struct mm_struct *mm, enum vm_event_item idx); >> +static inline void mem_cgroup_count_vm_event(struct mm_struct *mm, >> + enum vm_event_item idx) >> +{ >> + if (mem_cgroup_disabled() || !mm) >> + return; >> + __mem_cgroup_count_vm_event(mm, idx); >> +} > > Does the !mm case occur frequently enough to justify inlining it, or > should that test remain out-of-line? > I think this should be out-of-line. Thanks, -Kame