From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753061AbbDGMTg (ORCPT ); Tue, 7 Apr 2015 08:19:36 -0400 Received: from cantor2.suse.de ([195.135.220.15]:40222 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750993AbbDGMTd (ORCPT ); Tue, 7 Apr 2015 08:19:33 -0400 Date: Tue, 7 Apr 2015 14:19:32 +0200 From: Michal Hocko To: David Rientjes Cc: Vlastimil Babka , Andrew Morton , Johannes Weiner , linux-mm@kvack.org, LKML Subject: Re: [PATCH -v2] mm, memcg: sync allocation and memcg charge gfp flags for THP Message-ID: <20150407121932.GE7935@dhcp22.suse.cz> References: <1426514892-7063-1-git-send-email-mhocko@suse.cz> <55098D0A.8090605@suse.cz> <20150318150257.GL17241@dhcp22.suse.cz> <55099C72.1080102@suse.cz> <20150318155905.GO17241@dhcp22.suse.cz> <5509A31C.3070108@suse.cz> <20150318161407.GP17241@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 03-04-15 18:34:18, David Rientjes wrote: > On Wed, 18 Mar 2015, Michal Hocko wrote: > > > memcg currently uses hardcoded GFP_TRANSHUGE gfp flags for all THP > > charges. THP allocations, however, might be using different flags > > depending on /sys/kernel/mm/transparent_hugepage/{,khugepaged/}defrag > > and the current allocation context. > > > > The primary difference is that defrag configured to "madvise" value will > > clear __GFP_WAIT flag from the core gfp mask to make the allocation > > lighter for all mappings which are not backed by VM_HUGEPAGE vmas. > > If memcg charge path ignores this fact we will get light allocation but > > the a potential memcg reclaim would kill the whole point of the > > configuration. > > > > Fix the mismatch by providing the same gfp mask used for the > > allocation to the charge functions. This is quite easy for all > > paths except for hugepaged kernel thread with !CONFIG_NUMA which is > > doing a pre-allocation long before the allocated page is used in > > collapse_huge_page via khugepaged_alloc_page. To prevent from cluttering > > the whole code path from khugepaged_do_scan we simply return the current > > flags as per khugepaged_defrag() value which might have changed since > > the preallocation. If somebody changed the value of the knob we would > > charge differently but this shouldn't happen often and it is definitely > > not critical because it would only lead to a reduced success rate of > > one-off THP promotion. > > > > Acked-by: Vlastimil Babka > > Signed-off-by: Michal Hocko > > Acked-by: David Rientjes Thanks! > I'm slightly surprised that this issue never got reported before. I am afraid not many people are familiar with the effect of /sys/kernel/mm/transparent_hugepage/{,khugepaged/}defrag knob(s). -- Michal Hocko SUSE Labs