Received: by 2002:a25:1104:0:0:0:0:0 with SMTP id 4csp62493ybr; Fri, 22 May 2020 00:43:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLEtTUjR5c9NIiM329Cs3feX8rb93HDJ1ijqREhWyVj409zuSbGeWDkC8CN1H1/eWUCHNO X-Received: by 2002:a17:906:2cc2:: with SMTP id r2mr6664752ejr.269.1590133420699; Fri, 22 May 2020 00:43:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590133420; cv=none; d=google.com; s=arc-20160816; b=RAHzooP5ny3eWQHhWGnuAmn6n3CMAJ7Zk9gXNKXuBl8CHKFuC3zH0AgJ+XVsiCAz4R H2TZqyuestSbPYijvmyi/kN/NKRqjMYbj31DnUU3G3T1jua7zj8M9UQm5Pfo0xynKhRL QHkSmXLZ16QeEMPsFWL1hJtPdWkY/A0pn8JeHZeRxOvfs8wYb5umk4SuiGpNJSRIp8wU 8PtYejlxaoIkjK7cIyki5aErjNh9eHqrSWlJQMmziC+Uv/Ad9n4O/3jhH91QMdut2Vki J2t0A+F5wzkoM0B8ZrPPYIg9ZovLVVzOP2r0a4aEDap98yprbyxpXQNvDYfUVxa7TmIT 1OAg== 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=aXRJpM2H138zpyDQC3RVrPvAFl58tr+boCaBOv+GSas=; b=DqhyN7LFhC6hTA/HfsORpJaiYbezPZeX7YfGAKr1Z9svpWDr2O+KrYZxnY/GkB9FTb NpuYdVyTZ870EvGUlfNM/cKUaZaqLJqxBvSupKyiToWlTq8r6CHfmWGA/w6CEqRXjVh0 hWk2ug2H5FnAio8I4dOipJuv+yq3bAEEUOWj2UM4VUdIanNMsfou81CcrU9Dy6+c32Ir nqPdnKQrWy9CCKDFow9oCLgFOp8IYT7Wd7mrj6AFk5LRq9FzpB8g2UrcKRYmtZuVEmDp cONJuGinlKdTSZzW3zCpxPgymYLdRAkxc2z4Wi/Q3MfE1DfGzAddpq/Wns5DJ4BGyVE+ QyKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iYSjYVIx; 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 be3si4177169edb.12.2020.05.22.00.43.17; Fri, 22 May 2020 00:43:40 -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=iYSjYVIx; 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 S1728797AbgEVHjJ (ORCPT + 99 others); Fri, 22 May 2020 03:39:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46444 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727839AbgEVHjI (ORCPT ); Fri, 22 May 2020 03:39:08 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32404C061A0E for ; Fri, 22 May 2020 00:39:08 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id i68so7627208qtb.5 for ; Fri, 22 May 2020 00:39:08 -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=aXRJpM2H138zpyDQC3RVrPvAFl58tr+boCaBOv+GSas=; b=iYSjYVIxRMRCxIl0eNKt5e6cmbSPMoPhaBitsxSf1t4HoLcAJBw6fjtdnM+zgrN/1T hFl81xc4k+M53+PP+DpAgMTI6J7GQ+KWq8DD1o4URrb1BneAjMarPrDPipDE/pGCCT2h r52AZvbL1/0CrQSVEZK6QZup6S4Oq+vQA4StLYq6TOZlyoLP9GD1cXU/I4HW1h0n5uaj 1DWi+IS1AN+n8QogJ7XDp3aiS5lVRkhRoyf//L0urD4e0odbrLs8P65cX81Msd/Nn2Mp FBVexCz/sVIbIoiyVhHPM0Wvnb6Md3u9XVx2NMUTM2MOo29R7GFk6nHda+9+s7EG+JcF M/Fg== 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=aXRJpM2H138zpyDQC3RVrPvAFl58tr+boCaBOv+GSas=; b=GQ8dua0L6/s7o4tGiCSg7ZSMj1v3afNDjhvzwWGCHjXzhyL/bNTObwb7pPpdwUhOG/ uZKsH2jf0zSEmKWay3DsyM9CBA//2fhbiTD/SV+8/WDNWc+4zJHhPnr7VfigbTLCG3w3 NeUJgshWh/X4GJVGZ7z+uN4M3cZkhNd2Y8XtL2KBhoE195ikyus+7+aC9k8aJc9Y/LDE vTmfH7Sj6ck7lMadFBBMyAg28Tmko2dccFgkndlQdJ96Uuiv0kBdzHzb64DtZeg8jABu UpDodLt6VoAX3eP9AWZanBFOZ41BeUwKtC1VbwpzmA/voATe6IoAOzSo5bxiU4YxtOZm iuqg== X-Gm-Message-State: AOAM531TJY93xaeuXflAeKDWOidalzJuw1yOiO5PJflRCB6AKrNHCVXf XvlBvL39PG2Uwq6PGcI5tXZIGeTgxMF7islld3k= X-Received: by 2002:aed:2252:: with SMTP id o18mr14932634qtc.35.1590133147339; Fri, 22 May 2020 00:39:07 -0700 (PDT) MIME-Version: 1.0 References: <1589764857-6800-1-git-send-email-iamjoonsoo.kim@lge.com> <1589764857-6800-5-git-send-email-iamjoonsoo.kim@lge.com> <01cdaaea-892a-2b29-edbd-279611f418b0@oracle.com> In-Reply-To: <01cdaaea-892a-2b29-edbd-279611f418b0@oracle.com> From: Joonsoo Kim Date: Fri, 22 May 2020 16:38:59 +0900 Message-ID: Subject: Re: [PATCH 04/11] mm/hugetlb: unify hugetlb migration callback function To: Mike Kravetz Cc: Andrew Morton , Linux Memory Management List , LKML , kernel-team@lge.com, Vlastimil Babka , Christoph Hellwig , Roman Gushchin , Naoya Horiguchi , Michal Hocko , 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 5=EC=9B=94 22=EC=9D=BC (=EA=B8=88) =EC=98=A4=EC=A0=84 5:54, M= ike Kravetz =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On 5/17/20 6:20 PM, js1304@gmail.com 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 one more field on to > > the alloc_control and handles this exception. > > > > Signed-off-by: Joonsoo Kim > > --- > > include/linux/hugetlb.h | 8 -------- > > mm/hugetlb.c | 23 ++--------------------- > > mm/internal.h | 1 + > > mm/mempolicy.c | 3 ++- > > 4 files changed, 5 insertions(+), 30 deletions(-) > > > > diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > > index 6da217e..4892ed3 100644 > > --- a/include/linux/hugetlb.h > > +++ b/include/linux/hugetlb.h > > @@ -505,8 +505,6 @@ struct huge_bootmem_page { > > > > struct page *alloc_migrate_huge_page(struct hstate *h, > > struct alloc_control *ac); > > -struct page *alloc_huge_page_node(struct hstate *h, > > - struct alloc_control *ac); > > struct page *alloc_huge_page_nodemask(struct hstate *h, > > struct alloc_control *ac); > > struct page *alloc_huge_page_vma(struct hstate *h, struct vm_area_stru= ct *vma, > > @@ -755,12 +753,6 @@ static inline void huge_ptep_modify_prot_commit(st= ruct vm_area_struct *vma, > > struct hstate {}; > > > > static inline struct page * > > -alloc_huge_page_node(struct hstate *h, struct alloc_control *ac) > > -{ > > - return NULL; > > -} > > - > > -static inline struct page * > > alloc_huge_page_nodemask(struct hstate *h, struct alloc_control *ac) > > { > > return NULL; > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index 859dba4..60b0983 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -1981,31 +1981,12 @@ struct page *alloc_buddy_huge_page_with_mpol(st= ruct hstate *h, > > } > > > > /* page migration callback function */ > > -struct page *alloc_huge_page_node(struct hstate *h, > > - struct alloc_control *ac) > > -{ > > - struct page *page =3D NULL; > > - > > - ac->gfp_mask |=3D htlb_alloc_mask(h); > > - if (ac->nid !=3D NUMA_NO_NODE) > > - ac->gfp_mask |=3D __GFP_THISNODE; > > - > > - spin_lock(&hugetlb_lock); > > - if (h->free_huge_pages - h->resv_huge_pages > 0) > > - page =3D dequeue_huge_page_nodemask(h, ac); > > - spin_unlock(&hugetlb_lock); > > - > > - if (!page) > > - page =3D alloc_migrate_huge_page(h, ac); > > - > > - return page; > > -} > > - > > -/* page migration callback function */ > > struct page *alloc_huge_page_nodemask(struct hstate *h, > > struct alloc_control *ac) > > { > > ac->gfp_mask |=3D htlb_alloc_mask(h); > > + if (ac->thisnode && ac->nid !=3D NUMA_NO_NODE) > > + ac->gfp_mask |=3D __GFP_THISNODE; > > > > spin_lock(&hugetlb_lock); > > if (h->free_huge_pages - h->resv_huge_pages > 0) { > > diff --git a/mm/internal.h b/mm/internal.h > > index 75b3f8e..574722d0 100644 > > --- a/mm/internal.h > > +++ b/mm/internal.h > > @@ -618,6 +618,7 @@ struct alloc_control { > > int nid; > > nodemask_t *nmask; > > gfp_t gfp_mask; > > + bool thisnode; > > I wonder if the new field is necessary? > > IIUC, it simply prevents the check for NUMA_NO_NODE and possible setting > of __GFP_THISNODE in previous alloc_huge_page_nodemask() calling sequence= s. > However, it appears that node (preferred_nid) is always set to something > other than NUMA_NO_NODE in those callers. Okay. I will check it. > It obviously makes sense to add the field to guarantee no changes to > functionality while making the conversions. However, it it is not really > necessary then it may cause confusion later. Agreed. Thanks.