Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp4325318ybt; Mon, 6 Jul 2020 01:35:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKWEEoG39XG0d5+CaYaeW/+GKE44HvGtFDojcgqqwRFqA95zt6HDRMhIznJ1aLuKr4gkCA X-Received: by 2002:a17:907:7244:: with SMTP id ds4mr33698441ejc.509.1594024547953; Mon, 06 Jul 2020 01:35:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594024547; cv=none; d=google.com; s=arc-20160816; b=lKJ441Xu3nG8DIQVMvl0pHUOEcSCLhGAtkuswjfyjqemFuHna3RV3eCQtTAAtu/IWE 7XQzHIEOlm8DT3h1QA9wmZqMqvkTD2c6fWjHxEnRSzBWSY975H5P4sMTSWwIX63x9U6p CAOTpIkj/Yu6pxmf8j6rmpniVULeA5l192/WMQZuf+SKdtby6UOUghwLMphOxAJA34S3 yL/PlHhdR66/98MA9APWRG78d9noiPSp+s4k1sFoEqB7xpp/bgH/QhJE6cVlC6jHBo1Z NIPSt516Z3OB6Z4wLh7PBzYxkvBPiYgxQXbhOLMfPeqH62RUawhNPZRqx6Q7Y8JONnhR q4+w== 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=UkKwMcyV/GIfNduaGOpb0yO+n875IEZ+a5vFi7DoFpk=; b=mHLHuPNcIPtOUAMpqZJZ8h4H8zbLjQopQd/Kc1Pgo606aQr3sweGFVe9M3+UyMTmPN GjZyfoN9uqDk45X41Pw7+nl7ktmj2TWpQbWPeJ3CCVXbcXFn3PUMmaFALcxI9HdBojj0 c7O1dj9GGtwzIPko8Hd92w+BdKQsAnF+Gb8UMwTuQlUXV/3V/Dr8L951lCIdAHJ2wgAC 8eAiGBK0Dydc+oDG0r9kfM/4gf4beCZBwdx7mk5A4V7IN/QT6SSCR0ixu2bLyc08R26T ghgLb6ngVmJDcZJEyi8eHnyUdv1IpMkRvfTr+TLyu37ZaUgUnErVV1qQE1yTN9ZeX3sx +TKA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DIf6Nsqe; 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 dp14si15748193ejc.412.2020.07.06.01.35.17; Mon, 06 Jul 2020 01:35:47 -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=DIf6Nsqe; 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 S1728237AbgGFIeh (ORCPT + 99 others); Mon, 6 Jul 2020 04:34:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726001AbgGFIeg (ORCPT ); Mon, 6 Jul 2020 04:34:36 -0400 Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8A0CC061794 for ; Mon, 6 Jul 2020 01:34:36 -0700 (PDT) Received: by mail-qv1-xf44.google.com with SMTP id m8so12611193qvk.7 for ; Mon, 06 Jul 2020 01:34:36 -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=UkKwMcyV/GIfNduaGOpb0yO+n875IEZ+a5vFi7DoFpk=; b=DIf6NsqeHVipKmVGsTJqd0GUJh0l+C6ZQxY2ih+ict7nQ1yoDCOZ9fNe8A4UoyjpaM uDH1M1E6zSsDUgV/bOeuHpDnRu2+vdPJIcKI2atc0fIcSgzXgW2MNZaIhA1jrOtb+s1F hath9V1gbPmd/NeroyZBPcDq2X+ZAfs0UvN5Tz7y6WdFqIftTifpOJdWixbpIgeyHsgk mosNhaIyCEIHAK4Z5QYQp99hforMNcMTDO8UevE/n9XK+hrZ8l6Ce6oz4acoMmvXRvhf +YikJlULjh7ZHAzmZ0S3Ad8td4BocD1NYEux4809TroeBRQh0ht/gWDTvb2/eEiJxzlR nVHA== 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=UkKwMcyV/GIfNduaGOpb0yO+n875IEZ+a5vFi7DoFpk=; b=mIOV5Ak1vHX31f97DbAR5hG/98/Ia27m76x3goeJRUCste1gh3+KoVP1/h3KTAXB+L K7nG+Giq1j4xEIRbgbxK+dDH17cEZi1l4cOCj6XUEJL99ZYSrQGbWnQQdzsgLlIoMtaK A/ReKtDc7jJwqguDYhpaOXoHHcOZ0C+t3Gvs10NjxQ8Luvt4QTCl4C4AmGAKOKOAQEP0 q1AWCkWN6l0yq4YfrHinZsI7N7pYgvH0y/omhyMI7EobXklxNiHQSCdmnVNk+/h5Pk8H t8Zm4DeqgD4IwndCe7b+0BoNs7Hs4+qGzTJsCMIn2yfY6srNKrr2LGXA1p93fSpGB9I0 oWhQ== X-Gm-Message-State: AOAM530GNAoE9S3pxAsXUs8YUE+IgTDwGZ6ooM28XsXyDdhLxX/C0oxC VGA+NNgBYyQQqe/8NJtBCQ+mq8RSo5nmhuJuNtw= X-Received: by 2002:a0c:99c5:: with SMTP id y5mr22989544qve.66.1594024475887; Mon, 06 Jul 2020 01:34:35 -0700 (PDT) MIME-Version: 1.0 References: <1592892828-1934-1-git-send-email-iamjoonsoo.kim@lge.com> <1592892828-1934-7-git-send-email-iamjoonsoo.kim@lge.com> <1693d7a8-4384-8fd8-69a2-55552329a34d@suse.cz> In-Reply-To: <1693d7a8-4384-8fd8-69a2-55552329a34d@suse.cz> From: Joonsoo Kim Date: Mon, 6 Jul 2020 17:34:24 +0900 Message-ID: Subject: Re: [PATCH v3 6/8] mm/gup: use a standard migration target allocation callback To: Vlastimil Babka Cc: Andrew Morton , Linux Memory Management List , LKML , kernel-team@lge.com, Christoph Hellwig , Roman Gushchin , Mike Kravetz , 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 7=EC=9B=94 4=EC=9D=BC (=ED=86=A0) =EC=98=A4=EC=A0=84 12:56, V= lastimil Babka =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On 6/23/20 8:13 AM, js1304@gmail.com wrote: > > From: Joonsoo Kim > > > > There is a well-defined migration target allocation callback. > > It's mostly similar with new_non_cma_page() except considering CMA page= s. > > > > This patch adds a CMA consideration to the standard migration target > > allocation callback and use it on gup.c. > > > > Signed-off-by: Joonsoo Kim > > Acked-by: Vlastimil Babka > > But a suggestion below. > > > --- > > mm/gup.c | 57 ++++++++-------------------------------------------= ------ > > mm/internal.h | 1 + > > mm/migrate.c | 4 +++- > > 3 files changed, 12 insertions(+), 50 deletions(-) > > > > diff --git a/mm/gup.c b/mm/gup.c > > index 15be281..f6124e3 100644 > > --- a/mm/gup.c > > +++ b/mm/gup.c > > @@ -1608,56 +1608,15 @@ static bool check_dax_vmas(struct vm_area_struc= t **vmas, long nr_pages) > > } > > > > #ifdef CONFIG_CMA > > -static struct page *new_non_cma_page(struct page *page, unsigned long = private) > > +static struct page *alloc_migration_target_non_cma(struct page *page, = unsigned long private) > > { > > ... > > > + struct migration_target_control mtc =3D { > > + .nid =3D page_to_nid(page), > > + .gfp_mask =3D GFP_USER | __GFP_NOWARN, > > + .skip_cma =3D true, > > + }; > > > > - return __alloc_pages_node(nid, gfp_mask, 0); > > + return alloc_migration_target(page, (unsigned long)&mtc); > > Do we really need this wrapper? The only user is check_and_migrate_cma_pa= ges so > just opencode it? This wrapper exists for setting up a different nid for each page. However, as you suggested in the next reply, we can remove this wrapper if NUMA_NO_NODE handling is added to the standard function. I will add NUMA_NO= _NODE handling to the standard function and remove this wrapper. Thanks.