From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B8AEC433DF for ; Fri, 26 Jun 2020 04:49:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EDB3820775 for ; Fri, 26 Jun 2020 04:49:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="k1zFq+VA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EDB3820775 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7675B6B0003; Fri, 26 Jun 2020 00:49:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 716FD6B0005; Fri, 26 Jun 2020 00:49:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6529D6B0006; Fri, 26 Jun 2020 00:49:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0035.hostedemail.com [216.40.44.35]) by kanga.kvack.org (Postfix) with ESMTP id 4A35A6B0003 for ; Fri, 26 Jun 2020 00:49:28 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E9E3B824556B for ; Fri, 26 Jun 2020 04:49:27 +0000 (UTC) X-FDA: 76970134374.30.fruit70_010f9ac26e52 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id C1E08180B3C83 for ; Fri, 26 Jun 2020 04:49:27 +0000 (UTC) X-HE-Tag: fruit70_010f9ac26e52 X-Filterd-Recvd-Size: 4664 Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Fri, 26 Jun 2020 04:49:27 +0000 (UTC) Received: by mail-qt1-f193.google.com with SMTP id q22so85013qtl.2 for ; Thu, 25 Jun 2020 21:49:27 -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=LFYDMUKQrW0T4SH1uN8ylIu3ETCULxHbKqmp1cm62qk=; b=k1zFq+VAzqOSlxMiA0G5gBJLoAJY6P0qFBiHQQzT5vjMoyOXdAFJUxM5VhxBJyZvOx W4Y3y2Q5SAZ8YE9RlGUvf4uDLfY/8CEk8IY6DffPP6QB4Hm1yBPL9FagGmMMxWvDSzaW 9nd73O9fsMBqAyN1EJR2ueeWkocpwSTKIQdgslJSwA9eEobG0k+ijyiXtLnFLysBGqcJ 0HrTpfvVAsJNV8QArBdBfPDO6krzFOnj6AeLLwDds4Thk7KMPmv3y+ViRLbN5QmiUitz FHiiHP/yVaSIFr/zWQCTVtdn2lbOrCN0QgpqHSfUgXiB2Ced8Bu0FL04rGKcVMyqF9Qy Mevw== 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=LFYDMUKQrW0T4SH1uN8ylIu3ETCULxHbKqmp1cm62qk=; b=XxywmgcaQoz+poBssOOKgzAH36HFIF5iBGvYmaijOG626TBSJiMgbcscidoMn8gXrH HYKyEjEBFF4xHfjRlqngZRosa89VQh1zbTOkkBVqnDs117Ki9r9+ZDRVGV7AnkqIK3af zvMEspzTZY8nITqTCwqFTbVQApL7Gm8U+l5E154wy/gSOHG3CRvZSySwFrOD+AAQW9VZ lTqcvBnYMqqVxX4SPQreDLh6gkjdVcYODUIaQwajl8uQ66Ln00KHE9/gl5txAoREuyB6 FUQM+KR5R2a+pfBxdGlXoWDFb7yWhTikpGjCGEbyGfSG1tSceRlHVoVrELzecatMwkYk UvOA== X-Gm-Message-State: AOAM532y9SIs9vhX0cF5tMbNP2QYUMGd+6MEQ+uyRbLCKTQflPhgTfon QzJOHTyHrdLuk6c9oOov9mWUTkT9L2dtEOn7HZo= X-Google-Smtp-Source: ABdhPJz8DxP+lZdaXieeYFvOpq4grToe+5JIrMlWyBrb0g7FKmjCCPPYfY2OO1oxh2fKCHaVWrzHFNkilBcUjzNVr/A= X-Received: by 2002:aed:2359:: with SMTP id i25mr984146qtc.194.1593146966697; Thu, 25 Jun 2020 21:49:26 -0700 (PDT) MIME-Version: 1.0 References: <1592892828-1934-1-git-send-email-iamjoonsoo.kim@lge.com> <1592892828-1934-5-git-send-email-iamjoonsoo.kim@lge.com> <20200625115422.GE1320@dhcp22.suse.cz> In-Reply-To: <20200625115422.GE1320@dhcp22.suse.cz> From: Joonsoo Kim Date: Fri, 26 Jun 2020 13:49:15 +0900 Message-ID: Subject: Re: [PATCH v3 4/8] mm/hugetlb: make hugetlb migration callback CMA aware 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 X-Rspamd-Queue-Id: C1E08180B3C83 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 2020=EB=85=84 6=EC=9B=94 25=EC=9D=BC (=EB=AA=A9) =EC=98=A4=ED=9B=84 8:54, M= ichal Hocko =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > On Tue 23-06-20 15:13:44, Joonsoo Kim wrote: > > From: Joonsoo Kim > > > > new_non_cma_page() in gup.c which try to allocate migration target page > > requires to allocate the new page that is not on the CMA area. > > new_non_cma_page() implements it by removing __GFP_MOVABLE flag. This w= ay > > works well for THP page or normal page but not for hugetlb page. > > Could you explain why? I mean why cannot you simply remove __GFP_MOVABLE > flag when calling alloc_huge_page_nodemask and check for it in dequeue > path? If we remove __GFP_MOVABLE when calling alloc_huge_page_nodemask, we cannot use the page in ZONE_MOVABLE on dequeing. __GFP_MOVABLE is not only used for CMA selector but also used for zone sele= ctor. If we clear it, we cannot use the page in the ZONE_MOVABLE even if it's not CMA pages. For THP page or normal page allocation, there is no way to avoid this weakness without introducing another flag or argument. For me, introducing another flag or argument for these functions looks over-engineering so I don't change them and leave them as they are (removing __GFP_MOVABLE). But, for alloc_huge_page_nodemask(), introducing a new argument doesn't seem to be a problem since it is not a general function but just a migration target allocation function. If you agree with this argument, I will add more description to the patch. Thanks.