Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3342882ybt; Mon, 29 Jun 2020 23:45:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwQerXu7UAOaPWjIY3DvMumwZCcNBJbHebGbsxiKL0s024j1p9yRV0dyq9gQFu+0p8gGTnf X-Received: by 2002:a50:da44:: with SMTP id a4mr15227125edk.379.1593499517208; Mon, 29 Jun 2020 23:45:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593499517; cv=none; d=google.com; s=arc-20160816; b=CXQS5A5eqBDRcKNr9B+ME3k/N4zzAiU9LRvf5QVbc8VLtmEHTmGCz2dsOg6ykZEqin zhB/sdJUtR3F/upBewfF49pBBWGC7C3yy1ySyPIKzc0cQ54ju9E0+GUbgRPClY9cLjTB Us3ZJhjpAIs/rZHPFko8Vi40aN6nusLZnELKVDx4grq6NDBxhvAAPxjOwqJwoZgRWiil gEoQmd5ueTgxYIX87DUt2zGtDTavRQCDluWyvL43U9RdkOmILtreNl/9XWGxtGAKwgV7 aWtuhoM72RG7RK9lragZBTtGtWaSTVpMpD48MhnAAPipano9cJRVjACu/OPD2cSltBMY QMRg== 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=T68iAtCbsB3kK12Vx7XZijyxS7QJWskLFeow15TOzcM=; b=VLQDsEfbBeYGQFmg9fvAkvn2QjVejBHanKc70zN33BRE2yIF0RNApkpugJmK9Lvwvh JTN8OSVwmzNEyhvFESuVmhlOfZ6ZACykJ7VmmNLzAF3OhWkao6Tfl7DkVgfrsq1+ZOH/ j4Y0bwZM7XhXEMk08EcA5zSHzw1i4BsDTXIceM0XaWKQWUB1WfUHaGz6BAWH2z/VU8kZ Defns2inJsyph6ZFeZzyZMwLa9mQi2SsjvIM3oEH45GFcj55t31McFn7/e9wrIeuCzWR FeU93Etg89+wBKbJLBKU45cRzatsa4V9znt8KoO880wLAib702lzZMjt3x8VhgWezZOx OR+w== 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 g4si1402979edf.452.2020.06.29.23.44.54; Mon, 29 Jun 2020 23:45:17 -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 S1730392AbgF3GnB (ORCPT + 99 others); Tue, 30 Jun 2020 02:43:01 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:39247 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730002AbgF3GnA (ORCPT ); Tue, 30 Jun 2020 02:43:00 -0400 Received: by mail-ed1-f65.google.com with SMTP id d18so9436384edv.6 for ; Mon, 29 Jun 2020 23:42:59 -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=T68iAtCbsB3kK12Vx7XZijyxS7QJWskLFeow15TOzcM=; b=Bi6o3EFRtSYRn1TN9e83RHGcvMwbO03f1QD7p+YxHHER1E63ZliaKt6X7kF1LuiTqr r23MEfHrZL7BYTyBCh6UEl8rS2azEb6Fpza2AnysEpR4qgxECfTxYlvh4qfQjeBMA9wd QFVUkIyhH1Z4D82yNXWJbUBNM4FV+CXtbFh3t4JfawUVVXVmjAnxCjyuMl1NkaZTvml4 s9siVub4Yh3yE5xwBHMv210yJzjEG1u+es0gv2VFB6Mz3htZI56pBCtVeneR2u/2cVqv uoaWlrx31q7WFccebUTwJ0tDxyl0JIuFqbkECfqV+f1jWB+b6lAvV4KChwo1xHbmsmlg 6z0w== X-Gm-Message-State: AOAM530Zy2tC36EhoI5+6qIvCLb6rd7Bh/1JmswHcTF14ttSXao5vhp7 1+6fjX4D5ltw8V/0rntJrIg= X-Received: by 2002:a05:6402:559:: with SMTP id i25mr13399059edx.35.1593499378880; Mon, 29 Jun 2020 23:42:58 -0700 (PDT) Received: from localhost (ip-37-188-168-3.eurotel.cz. [37.188.168.3]) by smtp.gmail.com with ESMTPSA id m6sm1239903ejq.85.2020.06.29.23.42.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 23:42:58 -0700 (PDT) Date: Tue, 30 Jun 2020 08:42:56 +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: <20200630064256.GB2369@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> <20200626072324.GT1320@dhcp22.suse.cz> <20200629075510.GA32461@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 Tue 30-06-20 15:30:04, Joonsoo Kim wrote: > 2020년 6월 29일 (월) 오후 4:55, Michal Hocko 님이 작성: [...] > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index 57ece74e3aae..c1595b1d36f3 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -1092,10 +1092,14 @@ static struct page *dequeue_huge_page_nodemask(struct hstate *h, gfp_t gfp_mask, > > /* Movability of hugepages depends on migration support. */ > > static inline gfp_t htlb_alloc_mask(struct hstate *h) > > { > > + gfp_t gfp; > > + > > if (hugepage_movable_supported(h)) > > - return GFP_HIGHUSER_MOVABLE; > > + gfp = GFP_HIGHUSER_MOVABLE; > > else > > - return GFP_HIGHUSER; > > + gfp = GFP_HIGHUSER; > > + > > + return current_gfp_context(gfp); > > } > > > > static struct page *dequeue_huge_page_vma(struct hstate *h, > > > > If we even fix this general issue for other allocations and allow a > > better CMA exclusion then it would be implemented consistently for > > everybody. > > Yes, I have reviewed the memalloc_nocma_{} APIs and found the better way > for CMA exclusion. I will do it after this patch is finished. > > > Does this make more sense to you are we still not on the same page wrt > > to the actual problem? > > Yes, but we have different opinions about it. As said above, I will make > a patch for better CMA exclusion after this patchset. It will make > code consistent. > I'd really appreciate it if you wait until then. As I've said I would _prefer_ simplicity over "correctness" if it is only partial and hard to reason about from the userspace experience but this is not something I would _insist_ on. If Mike as a maintainer of the code is ok with that then I will not stand in the way. But please note that a missing current_gfp_context inside htlb_alloc_mask is a subtle bug. I do not think it matters right now but with a growing use of scoped apis this might actually hit some day so I believe we want to have it in place. Thanks! -- Michal Hocko SUSE Labs