Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp2116104ima; Thu, 25 Oct 2018 09:46:16 -0700 (PDT) X-Google-Smtp-Source: AJdET5eDQEhpUPe+vARn0p0ML52OnKBTlGzApyCFZqJzfJzzl268lNPRuAQeNcHieT7YeUwRESmg X-Received: by 2002:a17:902:8347:: with SMTP id z7-v6mr2194468pln.111.1540485976766; Thu, 25 Oct 2018 09:46:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540485976; cv=none; d=google.com; s=arc-20160816; b=cSPsVuVDhaYySuyUc+8JuxaLW5e62vv5KflZiW662dnf4oOJey5n7fVDAm+FVugoOJ cymIYwPXTnDO3b3pDxvPrCSB8w56Vk7dtqebACUklp2oH9+cL6izgCvlRwQp+3BRJFxd TZHXavOyF1EFWkLzd7qZ9QoQnAQM0UNRGpQILGdNbYI/3R2g5bfvkPm0g8mlny/SqqH/ /um+7ARrUjlbnhY4OYU3Nk17IehUICmxIOrxkYuD0t0Pd8MxAbbU7RTOV8ewYUdsn0us cM7kGZ/2Ud9Et86+mE3Uog8sD/ykmOOo5YLtHrAO1BeMm1BwdEYF9hXpbAYMDgogsTY5 dewA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jiF6KRaOIIc7rlES9CJQi0JIiguOnu/zFeH5vDJcmic=; b=S1Kr9B7+n2onSqWUJjAhx5q17ohRfrj3VYNKGb+JE5rAyJcHrj/S7GGTB8XZ1xDZJd Fi5h71uOE97/TKNvbs+26YWlBDAl5kg1JHNqbl9Q3hlWgWFwBspQmSA517qLzBnzqEs9 90/Jgj53vzmRRQu58blGgjzGaj+Vj2hXXBLML0d1S2ApvuTQvFLsFbddigvcQlTUNrUC vZfEzqtwlZWC5Io6Brw4JhuR9GzSgvVvLb+OBmi8shUILy+ZNQ14huCalIzCIQf12XZ+ aObjuiTRLGP8a8daAZuh+FAjy9+zvkmdUML4qSCkgot4VhjyVRxMc20Yu/kaSAQurADx an9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s21-v6si8635137pgj.90.2018.10.25.09.46.00; Thu, 25 Oct 2018 09:46:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727885AbeJZBS7 (ORCPT + 99 others); Thu, 25 Oct 2018 21:18:59 -0400 Received: from mx2.suse.de ([195.135.220.15]:45370 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727453AbeJZBS7 (ORCPT ); Thu, 25 Oct 2018 21:18:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 34CABAEAE; Thu, 25 Oct 2018 16:45:24 +0000 (UTC) Date: Thu, 25 Oct 2018 18:45:22 +0200 From: Michal Hocko To: Andrew Morton Cc: Vlastimil Babka , "Kirill A. Shutemov" , Mel Gorman , David Rientjes , Andrea Argangeli , Zi Yan , Stefan Priebe - Profihost AG , linux-mm@kvack.org, LKML Subject: Re: [PATCH 2/2] mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask Message-ID: <20181025164522.GU18839@dhcp22.suse.cz> References: <20180926133039.y7o5x4nafovxzh2s@kshutemo-mobl1> <20180926141708.GX6278@dhcp22.suse.cz> <20180926142227.GZ6278@dhcp22.suse.cz> <20181018191147.33e8d5e1ebd785c06aab7b30@linux-foundation.org> <20181019080657.GJ18839@dhcp22.suse.cz> <583b20e5-4925-e175-1533-5c2d2bab9192@suse.cz> <20181024161754.0d174e7c22113f4f8aad1940@linux-foundation.org> <983e0c59-99ef-796c-bfc4-00e67782d1f1@suse.cz> <20181025161410.GT18839@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 25-10-18 09:18:05, Andrew Morton wrote: > > > On October 25, 2018 9:14:10 AM PDT, Michal Hocko wrote: > > >Andrew. Do you want me to repost the patch or you plan to update the > >changelog yourself? > > Please send a replacement changelog and I'll paste it in? THP allocation mode is quite complex and it depends on the defrag mode. This complexity is hidden in alloc_hugepage_direct_gfpmask from a large part currently. The NUMA special casing (namely __GFP_THISNODE) is however independent and placed in alloc_pages_vma currently. This both adds an unnecessary branch to all vma based page allocation requests and it makes the code more complex unnecessarily as well. Not to mention that e.g. shmem THP used to do the node reclaiming unconditionally regardless of the defrag mode until recently. This was not only unexpected behavior but it was also hardly a good default behavior and I strongly suspect it was just a side effect of the code sharing more than a deliberate decision which suggests that such a layering is wrong. Get rid of the thp special casing from alloc_pages_vma and move the logic to alloc_hugepage_direct_gfpmask. __GFP_THISNODE is applied to the resulting gfp mask only when the direct reclaim is not requested and when there is no explicit numa binding to preserve the current logic. Please note that there's also a slight difference wrt MPOL_BIND now. The previous code would avoid using __GFP_THISNODE if the local node was outside of policy_nodemask(). After this patch __GFP_THISNODE is avoided for all MPOL_BIND policies. So there's a difference that if local node is actually allowed by the bind policy's nodemask, previously __GFP_THISNODE would be added, but now it won't be. From the behavior POV this is still correct because the policy nodemask is used. -- Michal Hocko SUSE Labs