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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 380D7C433E0 for ; Fri, 17 Jul 2020 11:08:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D03A62070E for ; Fri, 17 Jul 2020 11:08:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D03A62070E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 211388D0032; Fri, 17 Jul 2020 07:08:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C30B8D0030; Fri, 17 Jul 2020 07:08:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B0838D0032; Fri, 17 Jul 2020 07:08:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by kanga.kvack.org (Postfix) with ESMTP id EA2E88D0030 for ; Fri, 17 Jul 2020 07:08:10 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 648201848892D for ; Fri, 17 Jul 2020 11:08:10 +0000 (UTC) X-FDA: 77047293540.05.sort98_5d1692a26f0a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 39E591821B295 for ; Fri, 17 Jul 2020 11:08:10 +0000 (UTC) X-HE-Tag: sort98_5d1692a26f0a X-Filterd-Recvd-Size: 5702 Received: from mail-wm1-f66.google.com (mail-wm1-f66.google.com [209.85.128.66]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Jul 2020 11:08:09 +0000 (UTC) Received: by mail-wm1-f66.google.com with SMTP id w3so16412386wmi.4 for ; Fri, 17 Jul 2020 04:08:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=sW5ATIAUVqe473Xw/kpcZ/C6jQAJpg7NFPCXiZkdips=; b=bHWwx7DwG4m9VTjtskKvb39b1mThksZZuDpNBOYjJR3Fpze5Q/ByAHNVzan5XG8Yrq 9yH98AMwzP8GaG26rggcE0fXI8+3F/mlLGT/VINqKF9flrXQlG3NgXQbuST90Ei/OsI5 +bIAc7+VnyH8X3xAeaEKGzKeO3OJOnYxjfth9DOxBOHwg6b2W+/x7jHvRwoPo9NjHVwV LfxM6czBsvzkbz1AuK9Iaq6nJTuY97KO8TpMzpsq+VqAH/K7/OmvzOj2KfgOlXQs8QQo SiWumhrMTbVgFF590xJL2iF6kh5zihjM7wC3XapxeVQlwfm0Jsv2n6T0EzoXWZ+JaqTr skMA== X-Gm-Message-State: AOAM533YqmCiTaFkBK+2ImU5d4m5RlUkvmzX6GG2PpKxU3ayfBF76mvf ORW1/1cS+GBnpBt7iL1RIjA= X-Google-Smtp-Source: ABdhPJxox0SFlm5xLzRoNdhcTImUK1TCwAQbeJsz4XT4q1d/BhaW2glSZ+rF8qALgUyM4jjsatD+7g== X-Received: by 2002:a1c:4d11:: with SMTP id o17mr8569690wmh.134.1594984088723; Fri, 17 Jul 2020 04:08:08 -0700 (PDT) Received: from localhost (ip-37-188-169-187.eurotel.cz. [37.188.169.187]) by smtp.gmail.com with ESMTPSA id w14sm13981638wrt.55.2020.07.17.04.08.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2020 04:08:07 -0700 (PDT) Date: Fri, 17 Jul 2020 13:08:06 +0200 From: Michal Hocko To: Joonsoo Kim Cc: Andrew Morton , Linux Memory Management List , LKML , kernel-team@lge.com, Vlastimil Babka , Christoph Hellwig , Roman Gushchin , Mike Kravetz , Naoya Horiguchi , "Aneesh Kumar K . V" , Joonsoo Kim Subject: Re: [PATCH 2/4] mm/gup: restrict CMA region by using allocation scope API Message-ID: <20200717110806.GI10655@dhcp22.suse.cz> References: <1594789529-6206-1-git-send-email-iamjoonsoo.kim@lge.com> <1594789529-6206-2-git-send-email-iamjoonsoo.kim@lge.com> <20200715082401.GC5451@dhcp22.suse.cz> <20200717082643.GC10655@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 39E591821B295 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 Content-Transfer-Encoding: quoted-printable 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: On Fri 17-07-20 18:28:16, Joonsoo Kim wrote: > 2020=EB=85=84 7=EC=9B=94 17=EC=9D=BC (=EA=B8=88) =EC=98=A4=ED=9B=84 5:2= 6, Michal Hocko =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > > > > On Fri 17-07-20 16:46:38, Joonsoo Kim wrote: > > > 2020=EB=85=84 7=EC=9B=94 15=EC=9D=BC (=EC=88=98) =EC=98=A4=ED=9B=84= 5:24, Michal Hocko =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84= =B1: > > > > > > > > On Wed 15-07-20 14:05:27, Joonsoo Kim wrote: > > > > > From: Joonsoo Kim > > > > > > > > > > We have well defined scope API to exclude CMA region. > > > > > Use it rather than manipulating gfp_mask manually. With this ch= ange, > > > > > we can now use __GFP_MOVABLE for gfp_mask and the ZONE_MOVABLE = is also > > > > > searched by page allocator. For hugetlb, gfp_mask is redefined = since > > > > > it has a regular allocation mask filter for migration target. > > > > > > > > > > Note that this can be considered as a fix for the commit 9a4e9f= 3b2d73 > > > > > ("mm: update get_user_pages_longterm to migrate pages allocated= from > > > > > CMA region"). However, "Fixes" tag isn't added here since it is= just > > > > > suboptimal but it doesn't cause any problem. > > > > > > > > But it is breaking the contract that the longterm pins never end = up in a > > > > cma managed memory. So I think Fixes tag is really due. I am not = sure > > > > about stable backport. If the patch was the trivial move of > > > > > > Previous implementation is correct since longterm pins never end up= in a CMA > > > managed memory with that implementation. It's just a different and = suboptimal > > > implementation to exclude the CMA area. This is why I don't add the= "Fixes"A > > > tag on the patch. > > > > But the current implementation calls memalloc_nocma_restore too early= so > > __gu_longterm_locked will migrate pages possibly to CMA ranges as the= re > > is no GFP_MOVABLE restriction in place. Or am I missing something? >=20 > IIUC, calling memalloc_nocma_restore() too early doesn't cause the > actual problem. >=20 > Final check is done by check_and_migrate_cma_pages() which is outside o= f > scope API. If we find a CMA page in between the gup range here, the pag= e is > migrated to the migration target page and this target page is allocated= by > new_non_cma_page(). >=20 > new_non_cma_page() try to allocate the page without __GFP_MOVABLE so > returned page will not be CMA area memory. Therefore, even if > memalloc_nocma_restore() is called early, there is no actual problem. Right you are! I have misread gfp_t gfp_mask =3D GFP_USER | __GFP_NOWARN and didn't realize that it doesn't include MOVABLE flag. Sorry about the noise! The issue is only formal coding style so Fixes tag could indeed cause more confusion than it would help. --=20 Michal Hocko SUSE Labs