From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752628AbbDDBeX (ORCPT ); Fri, 3 Apr 2015 21:34:23 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:35919 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752526AbbDDBeV (ORCPT ); Fri, 3 Apr 2015 21:34:21 -0400 Date: Fri, 3 Apr 2015 18:34:18 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Michal Hocko 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 In-Reply-To: <20150318161407.GP17241@dhcp22.suse.cz> Message-ID: 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> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 I'm slightly surprised that this issue never got reported before.