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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DF30C4332F for ; Wed, 2 Nov 2022 18:18:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8B3888E0002; Wed, 2 Nov 2022 14:18:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 83CBA8E0001; Wed, 2 Nov 2022 14:18:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DE108E0002; Wed, 2 Nov 2022 14:18:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 59D3F8E0001 for ; Wed, 2 Nov 2022 14:18:47 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1D25FAB167 for ; Wed, 2 Nov 2022 18:18:47 +0000 (UTC) X-FDA: 80089313094.05.9173E7F Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by imf28.hostedemail.com (Postfix) with ESMTP id 72699C0003 for ; Wed, 2 Nov 2022 18:18:46 +0000 (UTC) Received: by mail-pl1-f174.google.com with SMTP id u6so17336685plq.12 for ; Wed, 02 Nov 2022 11:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CdYKm5wdZipIcutmvlbbV3SRLDzTmAvD0R5AITtaDwQ=; b=WKGMtqnGUFEZ/CNX5AzbQ/FhR7nrJMzCa5zkAFrTr6uyWYNFdTVdCm7p8oanZs4h2V cbBie+UH1s35PXHnnh/5B9FKvIH6Ah0ODn8oaPKlf00e/BUkZLuDLiueRs1hAuKgK923 eBo9QDZVPIrbndZ2aJlLt3eTeks1sVGhf/FgZqWKs857vJL7vplOjWr2YdDowVg3N/xx B3A2/Jsm62mwW/kuk2Dg55G9Gi4RfQMVcnVZ8WokzYtNr0JYKFMUyQi1EKfNmV3e/l9N 8Vfobi2LoqvjATM2bKvEpQ5KF1vWPM2LIYl0zLqwT+CbaJga6uqLYzQlmbMBFPloCCwj qe4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CdYKm5wdZipIcutmvlbbV3SRLDzTmAvD0R5AITtaDwQ=; b=fBUmmKQZdMItOGrTez6gO2bjmCq66+s6oS9PCuymyORtNcHNfrmuizv+cA/HgMXFgR MB6/+G1aU8oN2eooT9vZ3Vxw/ypG62cKuTQKZCpmsVhmdxnQDJZXXmiHXKYnpirBfuns WMSJZhyh8ZA/0qOB/2rPvl3qfws/h9KyHxn1N3QyeH+KwrjLtjeYBJ88CPeNOZM5g4cV f6Vb6oqU+AgYigzq6rfnmVXKnNM6fQbNFNUU7O62Hob80zh3kJRFBHp4WTdU48huZDO2 eAy8JlqkJV5O5NG9cVYf6D1Er7ivUC/HMqL4d868rIXe9wRzSVcV/8EblbgKQ92H9OVB H3WQ== X-Gm-Message-State: ACrzQf3qZOwcDU3qXykXudGNA8YidbbAj9XZKqCGrg7Eic7ye8KlN622 iqyYOQUekxzvMVkVU1hnkvopYIcgC21e19LLA7A= X-Google-Smtp-Source: AMsMyM54X1Zpmkji1PfXTjwCNdQgHbqXfhZ13VKDHjuaxGhd0A4pd8WcqUOGEwJL2kX4PI/gWSshiLMErRJVJOz2Byw= X-Received: by 2002:a17:902:d512:b0:181:f1f4:fcb4 with SMTP id b18-20020a170902d51200b00181f1f4fcb4mr26418445plg.102.1667413125322; Wed, 02 Nov 2022 11:18:45 -0700 (PDT) MIME-Version: 1.0 References: <20221031183122.470962-1-shy828301@gmail.com> In-Reply-To: From: Yang Shi Date: Wed, 2 Nov 2022 11:18:32 -0700 Message-ID: Subject: Re: [PATCH] mm: don't warn if the node is offlined To: Michal Hocko Cc: "Zach O'Keefe" , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WKGMtqnG; spf=pass (imf28.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667413126; a=rsa-sha256; cv=none; b=ALg1gjW36FOHUniimXM5QaidxmbWoGk5yqIgll1Nvll8EI4OA9yE+CbBF/lE7pEQrrMU5Z tTO0oLva5GbZL+mHrlfVwPrbvXtQuzE7qknzxknAxPg4OpOsuHZNO8Zv8FN4mhjXPbEI2q POUYQ2/tCSS2eeAjcixNeJOz7+5Y07A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667413126; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CdYKm5wdZipIcutmvlbbV3SRLDzTmAvD0R5AITtaDwQ=; b=YtzKoFmitJpehRNwlgyf84Mu7J6EwIGFJLzfIJahyT7lWG4sD1dYaT3UtXYgWGS184l6xC Qgj2Ua9fonbZt7Uyf4E8Md06XbrufDLmWE1r2v75jwwD+TuSPi2uz82MrtSMsUyuyCixvp Z6kAa+YPcafe4Bw4IuoExbGtzb4X5Lc= X-Stat-Signature: fgopd4nd3wqbtym8pwbpgcbc8uj69pxi X-Rspamd-Queue-Id: 72699C0003 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WKGMtqnG; spf=pass (imf28.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.174 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1667413126-749052 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 Wed, Nov 2, 2022 at 10:47 AM Michal Hocko wrote: > > On Wed 02-11-22 10:36:07, Yang Shi wrote: > > On Wed, Nov 2, 2022 at 9:15 AM Michal Hocko wrote: > > > > > > On Wed 02-11-22 09:03:57, Yang Shi wrote: > > > > On Wed, Nov 2, 2022 at 12:39 AM Michal Hocko wrote: > > > > > > > > > > On Tue 01-11-22 12:13:35, Zach O'Keefe wrote: > > > > > [...] > > > > > > This is slightly tangential - but I don't want to send a new mail > > > > > > about it -- but I wonder if we should be doing __GFP_THISNODE + > > > > > > explicit node vs having hpage_collapse_find_target_node() set a > > > > > > nodemask. We could then provide fallback nodes for ties, or if some > > > > > > node contained > some threshold number of pages. > > > > > > > > > > I would simply go with something like this (not even compile tested): > > > > > > > > Thanks, Michal. It is definitely an option. As I talked with Zach, I'm > > > > not sure whether it is worth making the code more complicated for such > > > > micro optimization or not. Removing __GFP_THISNODE or even removing > > > > the node balance code should be fine too IMHO. TBH I doubt there would > > > > be any noticeable difference. > > > > > > I do agree that an explicit nodes (quasi)round robin sounds over > > > engineered. It makes some sense to try to target the prevalent node > > > though because this code can be executed from khugepaged and therefore > > > allocating with a completely different affinity than the original fault. > > > > Yeah, the corner case comes from the node balance code, it just tries > > to balance between multiple prevalent nodes, so you agree to remove it > > IIRC? > > Yeah, let's just collect all good nodes into a nodemask and keep > __GFP_THISNODE in place. You can consider having the nodemask per collapse_control > so that you allocate it only once in the struct lifetime. Actually my intention is more aggressive, just remove that node balance code. > > And as mentioned in other reply it would be really nice to hide this > under CONFIG_NUMA (in a standalong follow up of course). The hpage_collapse_find_target_node() function itself is defined under CONFIG_NUMA. > > -- > Michal Hocko > SUSE Labs