Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp342507ybt; Fri, 26 Jun 2020 00:25:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/V23bSgtaJ6ut8Vc4l2PhrWsu4AKnzN1D9LphnxknEis89+6KvdqmnXhTGXc7Kuu1me1J X-Received: by 2002:a17:906:94c4:: with SMTP id d4mr1369144ejy.232.1593156327249; Fri, 26 Jun 2020 00:25:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593156327; cv=none; d=google.com; s=arc-20160816; b=ckdNm7goJ2zNTxk5inEcPUe6JF5IyyrMyfNSRzCLeanJzQUboZvAAnQvIFiSAaUom4 EtWHndlNKVkFbZ0jkjN4d6lowJZXd6T604yyk43sWvmGQZr98H4H22Gb5VUPcdyblvwA s0GaiugbgjXM1vgJcTq0lf9fYAzCInXfr3DTUjVFf2Lt8d4TFxf2LW696irBIpfH3UIy YytObWvsoKjtPO+VtdcwR1QJcmYLZPzTTu/VP8K1hs8nO+/e1xpJhNPqsTSlNLxY9UPI qv+P5fqQB/zeYGip/xhoAu9y8tCWII00psMA3vccPYK2J4C6laepnvt52P6qFn0ClfJh rrmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=QEbKXP8FUgYuXuT6takZ5c8rrVZ/DcOt9hyzMr4EANc=; b=DQsi0gK8bJ8npYilEW6Tdxz4a25Lji94PyKTHSTxvbaznvIje/b/n1lR0PChhj428N pJvtOORLkeF7TvCvr9lezehd4DjreLP4HXMxYl39/1nY5CGJm0KWBRj95igpiAUdFAcI gJdrPrgAwPpW6mNS23P5ge5UbPNzlZrDam3SmdQ1jEzy26NSWhtIcgo6p4RLpXSvmmgX CwbXmi83ON1SG4FLVaa2acVi2PQ0kLZ3FYpmGY5DoBTEAPC9QLBIoXnSj22OVyTH6HrT c6EkMEvvrK6mdMSKLDXWelN0DqHG1xwATtJLRpvSz7hbKjHMR4wGxQh/3pHeTiiKiAaW Z1SA== ARC-Authentication-Results: i=1; mx.google.com; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cc21si6291854edb.40.2020.06.26.00.25.04; Fri, 26 Jun 2020 00:25:27 -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; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728632AbgFZHX3 (ORCPT + 99 others); Fri, 26 Jun 2020 03:23:29 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:39290 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728556AbgFZHX3 (ORCPT ); Fri, 26 Jun 2020 03:23:29 -0400 Received: by mail-ed1-f68.google.com with SMTP id d18so483910edv.6 for ; Fri, 26 Jun 2020 00:23:27 -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=QEbKXP8FUgYuXuT6takZ5c8rrVZ/DcOt9hyzMr4EANc=; b=nvVV0MJP64/SG+lyHDgDeWLgI4R/SMNY2NydzDFVtqcQq04DL7LYLVOdOKc7jyfNuj IvJuekRKiXLopxNZ5S9nePfpmvufhirKq0xl9vmsAa/eRMZRbfC1UzxRjl3/Ub5G583r W7FtBGtskGnebeWLF/0x+PDN9O1yR1uKfWnieFPXfm+2RDat5xNQRwoX9iXYxufe9VWa 009oztXRnuuWFKcM/3Ejo7G4+Y39FJ/5rd/07jSEHAeXV6tsGiPAtq0sk17SuRqZDsEs uzBl2fqAE+H9Wo1ooeF6uzKI6R0E1xH+8cMEnocfHcvyUiFHgdnsOfIVNWPnl7Ojxq2g PizQ== X-Gm-Message-State: AOAM530yo1DvAOKp6pXuHPEx/rI3K+LSjlvAlimKm9NSmzF97g/Uod9o EyU48bbtZAmEbQsOyB0/aO8= X-Received: by 2002:a50:e8c8:: with SMTP id l8mr2050076edn.386.1593156207272; Fri, 26 Jun 2020 00:23:27 -0700 (PDT) Received: from localhost (ip-37-188-168-3.eurotel.cz. [37.188.168.3]) by smtp.gmail.com with ESMTPSA id a2sm8817292ejg.76.2020.06.26.00.23.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 00:23:26 -0700 (PDT) Date: Fri, 26 Jun 2020 09:23:24 +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 , Joonsoo Kim Subject: Re: [PATCH v3 4/8] mm/hugetlb: make hugetlb migration callback CMA aware Message-ID: <20200626072324.GT1320@dhcp22.suse.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 26-06-20 13:49:15, Joonsoo Kim wrote: > 2020년 6월 25일 (목) 오후 8:54, Michal Hocko 님이 작성: > > > > 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 way > > > 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 > selector. 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. I really do not see why hugetlb and only the dequeing part should be special. This just leads to a confusion. From the code point of view it makes perfect sense to opt out CMA regions for !__GFP_MOVABLE when dequeing. So I would rather see a consistent behavior than a special case deep in the hugetlb allocator layer. -- Michal Hocko SUSE Labs