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.0 required=3.0 tests=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 1C1D8C433DF for ; Tue, 7 Jul 2020 19:00:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E11D7206CD for ; Tue, 7 Jul 2020 19:00:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E11D7206CD 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 4ED7D8D0014; Tue, 7 Jul 2020 15:00:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 475518D0003; Tue, 7 Jul 2020 15:00:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33E828D0014; Tue, 7 Jul 2020 15:00:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) by kanga.kvack.org (Postfix) with ESMTP id 1B7CF8D0003 for ; Tue, 7 Jul 2020 15:00:18 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9000482499A8 for ; Tue, 7 Jul 2020 19:00:17 +0000 (UTC) X-FDA: 77012195274.01.suit75_0912f1b26eb6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 5FEE720002D4ABFD for ; Tue, 7 Jul 2020 19:00:17 +0000 (UTC) X-HE-Tag: suit75_0912f1b26eb6 X-Filterd-Recvd-Size: 4032 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Jul 2020 19:00:16 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id k6so46388911wrn.3 for ; Tue, 07 Jul 2020 12:00:16 -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:in-reply-to; bh=VoyDJTI1cJ/dJyHAL3PoVYED5J0Stt74X8oxEEic8ao=; b=DW56VJFiK/GcQ9WfISSfjiKCGifCszmkKnHdx6OBU1JUjD83jBN/JTdfo3wkmUZrh3 agK0+S7Ig5xRCcTfBoxIhT9qJPqMi4zJ4SloSeihi21+JbRJedh2kapkwxldUgs3e3gm p52ZpgKazkCp+PDX9JdwLBM95A15YKgzdj4cePk2cB76YgpAd4NP3V7RZOOmtbvn1oUo +Z95hFLB2R23DZrxug06SK58iLYSVvkWDdB5oYzFirlW4ifC2oJeSDdqdkW9JnwykB7x iJU0AsJNoCmqQ0+MpGMcUWVg8FDgecwgItSYbSV9CMl6ctGvQ9thdo9LLktvMoQ8W2Xd UXqQ== X-Gm-Message-State: AOAM533sj41wq9ulfjc05sqSoZQwMVsgEp9aWZxUuSZFJCIHlv/dAlZG +YfES9Ukw1eoeDQNZBQvpc8= X-Google-Smtp-Source: ABdhPJyj3S6v1FPmg4uWREMeTffGzWqJbvJBFUP3wNgeFQT8ldjLochB7WGbW9hEpKcA9NtBo+LvEw== X-Received: by 2002:a5d:5441:: with SMTP id w1mr52781033wrv.381.1594148415773; Tue, 07 Jul 2020 12:00:15 -0700 (PDT) Received: from localhost (ip-37-188-179-51.eurotel.cz. [37.188.179.51]) by smtp.gmail.com with ESMTPSA id h84sm2540887wme.22.2020.07.07.12.00.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jul 2020 12:00:14 -0700 (PDT) Date: Tue, 7 Jul 2020 21:00:13 +0200 From: Michal Hocko To: Vlastimil Babka Cc: js1304@gmail.com, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@lge.com, Christoph Hellwig , Roman Gushchin , Mike Kravetz , Naoya Horiguchi , Joonsoo Kim Subject: Re: [PATCH v4 06/11] mm/migrate: make a standard migration target allocation function Message-ID: <20200707190013.GZ5913@dhcp22.suse.cz> References: <1594107889-32228-1-git-send-email-iamjoonsoo.kim@lge.com> <1594107889-32228-7-git-send-email-iamjoonsoo.kim@lge.com> <409b6e24-d143-a61c-95a3-1a55e1a6008e@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409b6e24-d143-a61c-95a3-1a55e1a6008e@suse.cz> X-Rspamd-Queue-Id: 5FEE720002D4ABFD X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 Tue 07-07-20 16:49:51, Vlastimil Babka wrote: > On 7/7/20 9:44 AM, js1304@gmail.com wrote: > > From: Joonsoo Kim > > > > There are some similar functions for migration target allocation. Since > > there is no fundamental difference, it's better to keep just one rather > > than keeping all variants. This patch implements base migration target > > allocation function. In the following patches, variants will be converted > > to use this function. > > > > Changes should be mechanical but there are some differences. First, Some > > callers' nodemask is assgined to NULL since NULL nodemask will be > > considered as all available nodes, that is, &node_states[N_MEMORY]. > > Second, for hugetlb page allocation, gfp_mask is ORed since a user could > > provide a gfp_mask from now on. > > I think that's wrong. See how htlb_alloc_mask() determines between > GFP_HIGHUSER_MOVABLE and GFP_HIGHUSER, but then you OR it with __GFP_MOVABLE so > it's always GFP_HIGHUSER_MOVABLE. Right you are! Not that it would make any real difference because only migrateable hugetlb pages will get __GFP_MOVABLE and so we shouldn't really end up here for !movable pages in the first place (not sure about soft offlining at this moment). But yeah it would be simply better to override gfp mask for hugetlb which we have been doing anyway. -- Michal Hocko SUSE Labs