Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1915188ybt; Thu, 2 Jul 2020 17:56:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxSAQrGcTJr6zfNSXW5eyGsk4H3+3xd2IlAADZX4GOWGvOdzq+vMgqF8uOQ1/DhSw9XEYzS X-Received: by 2002:a17:907:9484:: with SMTP id dm4mr31516865ejc.56.1593737794170; Thu, 02 Jul 2020 17:56:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593737794; cv=none; d=google.com; s=arc-20160816; b=DtKWxzCHYM/pAiZhz5EKv5BA5I2c/9UjDTARwYDp6/ylOFsXkjb/nsvlS0vVZLKX61 2QpstH3KyEAutgqyyg+Qly+5h/FRN+JHo/ykd17A9XQ0Wr/8LVS7nGCwX44Lq+aCSwhg bfQclz/ipUA8jkT1jbQZpjdhG0a/XLe1iqL07OKf3SQNLJXkeS4Vz6Yq8dVYwt7KpzoY lE4CJupLFOp1YOUBb7xOHozm9qZpuc0rPDXrLX3aI9dBgb/d/WlUMgAjAAGW/B2bRuGN o+Y4LmEO1nIFzIPjr/291aJO73VHnGaKH5JJ/2W/S+O5HlIyEX4D9/0B8iwIUelqVpJS SzKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=R14iB3HyxYLduKlG30SljyVyNrxsxoGgt0DcZz0ltyM=; b=Rw57QoZ9x+oVLcfRdu3s82qJvpUQIc3K2Wq8nmRy3Z2IT6w4TkDBPk7lokXyssH1Ym OjfjXWsc6DQ3WpscrqOCS6c9+8h1eUWQL4JgdX8C1SwwkiyTINBGScJLblHBQszu92rX 5z+vkxLTV8R+YQHEGTttfdfPqftZEQe7EMFZ3SKDqc3FFoQo01XJXxi8xi+jJuBs2CYQ NRIeOr+UMLSLdvf60gAhbwfMvPxtCJ99r270dxhGRzwROMzoe5tp+mLNtNpWJDRgMfGm QwwOBgmi5Kou1/CCarcoz08fZLS1yopvb8pwh8ip8kxog9V4sH1MGlNr6qygFvczEKA9 AipQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="bnD/q/x5"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cf17si7045336edb.488.2020.07.02.17.56.11; Thu, 02 Jul 2020 17:56:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="bnD/q/x5"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726302AbgGCAzp (ORCPT + 99 others); Thu, 2 Jul 2020 20:55:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726028AbgGCAzo (ORCPT ); Thu, 2 Jul 2020 20:55:44 -0400 Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A44D9C08C5C1 for ; Thu, 2 Jul 2020 17:55:44 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id z63so27439841qkb.8 for ; Thu, 02 Jul 2020 17:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=R14iB3HyxYLduKlG30SljyVyNrxsxoGgt0DcZz0ltyM=; b=bnD/q/x53LVZJ/xSMYP8vb81Ov2apN4dLC7hNDSSSxVJtpH+fiIgZ254xxZhU6MWyj BaaZCw4cL4EDwAFLaEatFAEfGutlmkD1fQpmnZXlngPugTXLX39nuj2B4uwJJPWeHFdU 8DiXLHrbfFEI66uNAU3lZfizvphLteL7SE2l4sXzOXmhe0oYiC90CiohXQXQbUgAJHv9 jmVy7ut2qxw7UEASFUsu99p8E1z0WScKTA8+7GDzAieM4I7F56DZHIesn45b2bA6eTtQ ZShndqIXZapd+sOthbBLqYJLiAlkgZSz41Z2n5y6SoVZpcyGLtnHHVlgccCT79Zrk32U j55g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=R14iB3HyxYLduKlG30SljyVyNrxsxoGgt0DcZz0ltyM=; b=Da1QjZuaCJpUqUJgiJS51iiUa1pLfJ54piprezqOD5hX5YE3PSJOhMYc3hWCfokWyf V2B6bXl2aqSwceAagaWK51jzM0izvpqFCVWQ28tYSpsTYnWAJAe1C5WAPe+3sPZUetoH 25Ewi2ogPgQiMumeJ++ETLx0sSPrN5To1Ik9U1lp6F26TVsw4Cf6bhYgt1TCJY09vB0p 2ZiLWsyYq0wT0vlmFEYTDwt9/dWUzyIewiCf7LRSMjHknoYF8iiZPfM82sm5Bsk3dZUC KV/rr8B8KmqyQPFnVaD7U9tmYhKNJ6Vy28H1jTQ0Xqnb1ahKmIei/MV2lnBtfQ/ewSYy rIcQ== X-Gm-Message-State: AOAM532ElTz3Fz0w/s0vgWvYTn2MATBBNdIQ7Hro+gHyBHkOm8ACC6P0 P1NzmBWTp0Vb3yCvArwH2ZRmSZj74B1osFx2cujqhdro X-Received: by 2002:a05:620a:a1b:: with SMTP id i27mr33128417qka.429.1593737743909; Thu, 02 Jul 2020 17:55:43 -0700 (PDT) MIME-Version: 1.0 References: <1592892828-1934-1-git-send-email-iamjoonsoo.kim@lge.com> <1592892828-1934-4-git-send-email-iamjoonsoo.kim@lge.com> <20200625112625.GD1320@dhcp22.suse.cz> In-Reply-To: From: Joonsoo Kim Date: Fri, 3 Jul 2020 09:55:33 +0900 Message-ID: Subject: Re: [PATCH v3 3/8] mm/hugetlb: unify migration callbacks To: Vlastimil Babka Cc: Michal Hocko , Andrew Morton , Linux Memory Management List , LKML , kernel-team@lge.com, Christoph Hellwig , Roman Gushchin , Mike Kravetz , Naoya Horiguchi , Joonsoo Kim Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2020=EB=85=84 7=EC=9B=94 3=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 1:13, Vl= astimil Babka =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On 6/26/20 6:02 AM, Joonsoo Kim wrote: > > 2020=EB=85=84 6=EC=9B=94 25=EC=9D=BC (=EB=AA=A9) =EC=98=A4=ED=9B=84 8:2= 6, Michal Hocko =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > >> > >> On Tue 23-06-20 15:13:43, Joonsoo Kim wrote: > >> > From: Joonsoo Kim > >> > > >> > There is no difference between two migration callback functions, > >> > alloc_huge_page_node() and alloc_huge_page_nodemask(), except > >> > __GFP_THISNODE handling. This patch adds an argument, gfp_mask, on > >> > alloc_huge_page_nodemask() and replace the callsite for > >> > alloc_huge_page_node() with the call to > >> > alloc_huge_page_nodemask(..., __GFP_THISNODE). > >> > > >> > It's safe to remove a node id check in alloc_huge_page_node() since > >> > there is no caller passing NUMA_NO_NODE as a node id. > >> > >> Yes this is indeed safe. alloc_huge_page_node used to be called from > >> other internal hugetlb allocation layer and that allowed NUMA_NO_NODE = as > >> well. Now it is called only from the mempolicy migration callback and > >> that always specifies a node and want to stick with that node. > >> > >> But I have to say I really dislike the gfp semantic because it is > >> different from any other allocation function I can think of. It > >> specifies what to be added rather than what should be used. > >> > >> Removing the function is ok but please use the full gfp mask instead > >> or if that is impractical for some reason (wich shouldn't be the case > >> as htlb_alloc_mask should be trivial to make static inline) make it > >> explicit that this is not a gfp_mask but a gfp modifier and explicitly > >> state which modifiers are allowed. > > > > Okay. I will try to solve your concern. Concrete solution is not yet pr= epared > > but perhaps I will use full gfp_mask by using htlb_alloc_mask() in call= er sites. > > Yeah, that should be feasible. alloc_huge_page_vma() already does > htlb_alloc_mask(h). In alloc_new_node_page() and new_page_nodemask() it w= ould be > consistent with the other cases handled there (THP and base). Okay. Will check it. Thanks.