Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp265859ybt; Thu, 25 Jun 2020 21:53:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxUC6u8r8kX8qn5nBQlsMWpvLi93LvoDrOVJJotXtP9Cy9UGjPDCxIaZ2QfDf988KxzP/Gm X-Received: by 2002:a50:fe07:: with SMTP id f7mr1545289edt.315.1593147209070; Thu, 25 Jun 2020 21:53:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593147209; cv=none; d=google.com; s=arc-20160816; b=w0Q30sxLq4PDqu2zKM2wcfjSGHS0dWji+8oWG/qABCYzNa/jBsNUzoSkUBGp9wt5GB /U+POIFJmoH9QzgSKehgWwommnNL8E1tXNUC0L18JOgKHEx5QsWHrmxysKJN9LSnEGyj Eu8jyNVwwv/uvoVGEh/hSwueEIQ6xsrAeHSLOcV7vGkREYXuH2c3LBddaip+MWM8blX0 lf2GTwUUdh/FeQw8ZznFN3q0EeiBYD6VrVEroAIlajbcnEAtaT4xJ//2rT81GzMQ94s4 AGMqXTCPNCYvX8bFuLKAWj+TIu/gPDDuf8jHBzSD4Lnx2/mAC31ZeJ17uP+ga4PAssia Mj9w== 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=tZ10wzKAlun9ezjnRJ6vAT4r5GZ70Nwas5NbwCUvzuo=; b=odHqD/RyYc5UK2+m/N4qCtUdEND0NXwIhxyvZYx/jlRLuHDkM44GSn1bYrf2D/Myli 2nATkSDqTPT4HXlfT/lHrfNRz/Zu63k1MrHC73lLgBFYqstAaPVXJOZbwBQwmGlbiE8v 3s22PTKeu55aCXfw3Fdyail5bJR8Ro/b2KPPMT84U5buxOn5kDM+SFcaq4k9n0U8+jLb 4sa3ZgZsmpqnumFNR6gJMlBH7eK/RLb2wd3hNZGB8UPiXU7BS5F+rZCTXKkuSuuHlx6i ABf9ma4BmuGZwBzpJcQETdgswOBAo3s2t0pq6J5JgDrQwZxkNnk5Crm5nX40fVrezEMF QziA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=EBYtwHmO; 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 be27si8170208edb.50.2020.06.25.21.53.06; Thu, 25 Jun 2020 21:53:29 -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=EBYtwHmO; 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 S1725945AbgFZECy (ORCPT + 99 others); Fri, 26 Jun 2020 00:02:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725280AbgFZECx (ORCPT ); Fri, 26 Jun 2020 00:02:53 -0400 Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60E48C08C5C1 for ; Thu, 25 Jun 2020 21:02:53 -0700 (PDT) Received: by mail-qv1-xf43.google.com with SMTP id a14so3933591qvq.6 for ; Thu, 25 Jun 2020 21:02:53 -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=tZ10wzKAlun9ezjnRJ6vAT4r5GZ70Nwas5NbwCUvzuo=; b=EBYtwHmORFxtCoCvv7YQq+Qs5V4daAv5+kVh3p/R+NpJlM6vO9JhKGny298bG/WkTc EXD25rwUZd7ArQD/PK0WUbwXdB1Aaf8R+CjkI+X3LzsjilJrZ7K2pfH725FpvDbN8RY3 NWbH7Gbsh5aRDUGlNp7+iO6iQfCpIq+UBpQ1V4/x8at4cvHpYcBRHSsvQ/9qiIEAxSGn JRtp/iFsbb+YVA6PcrTkNLf/OHF9I2SEksiOpns8x5Bu+heDBLlqt6Yj4CkSDZjb72fx LBLOWc0NHD6rTcPRQSIlIuu/hkI7OxfittbAtcG5j+rV0ECIMdaiHGBNA8A20pEiPrp0 4ilA== 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=tZ10wzKAlun9ezjnRJ6vAT4r5GZ70Nwas5NbwCUvzuo=; b=dyGYdjULDSdz6wwiOkYRZDqw+PgHrvgaL/2Yi/6TqXy7bP8s4U81ggsSh1z3IYTKLF N7DiJSD9pXUMZb/UNSOHIkuh1KXgExxW4IP9aG30d3BmOUUFwatNf2Bx6Vt4DFYSQ5+a kg0Ah/3DMa2ebuTUfT4mMmhB9od/MgBXjipUAVKiLYaO2wD00IQ8TgUtINsGneXvqCqT YK4Ai+eBsTQB38CEFt9ON5YAQoiePPPbCYgTTqTfzrmEhxZ40mTVXZDFq/VN182lSU4z Abpw8CIlCoa1IIeuVEcP+0dn4Ab1qYr+UFmYy71ScNLE/4W3VtFjQzZTTnqyx1FlKe7c M3hw== X-Gm-Message-State: AOAM530qN19WK9hudKT4unUfxiFqnaANSiIR0+HWvUuM4KprhPm1Zhm0 Cf6RbutBRLJgRPp6CNc+eyyHGTAEyYtAFwmuV74= X-Received: by 2002:a0c:b48e:: with SMTP id c14mr1358186qve.66.1593144172503; Thu, 25 Jun 2020 21:02:52 -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: <20200625112625.GD1320@dhcp22.suse.cz> From: Joonsoo Kim Date: Fri, 26 Jun 2020 13:02:41 +0900 Message-ID: Subject: Re: [PATCH v3 3/8] mm/hugetlb: unify migration callbacks To: Michal Hocko Cc: Andrew Morton , Linux Memory Management List , LKML , kernel-team@lge.com, Vlastimil Babka , 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 6=EC=9B=94 25=EC=9D=BC (=EB=AA=A9) =EC=98=A4=ED=9B=84 8:26, M= ichal 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 prepar= ed but perhaps I will use full gfp_mask by using htlb_alloc_mask() in caller s= ites. Thanks.