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 0EAB5C433FE for ; Wed, 2 Nov 2022 17:36:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 774DC8E0002; Wed, 2 Nov 2022 13:36:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 724BE8E0001; Wed, 2 Nov 2022 13:36:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EC898E0002; Wed, 2 Nov 2022 13:36:21 -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 4C7328E0001 for ; Wed, 2 Nov 2022 13:36:21 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 172D541312 for ; Wed, 2 Nov 2022 17:36:21 +0000 (UTC) X-FDA: 80089206162.08.17CFCE7 Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by imf04.hostedemail.com (Postfix) with ESMTP id B3D0840007 for ; Wed, 2 Nov 2022 17:36:20 +0000 (UTC) Received: by mail-pf1-f176.google.com with SMTP id k15so8978062pfg.2 for ; Wed, 02 Nov 2022 10:36:20 -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=HLhN9RFu9lLBh91C0UtWEhSEpP5/7mxewMk7n2SRYqo=; b=TCPbdfHFK8PufvJtOF7JykF9ukR2D408gd66jGiNn7p4qAkkkKLDADOOUXIwGXmVwn Eo1Z9Sfu69Uu0+K1t3oHEZUyCgEMDP4pxlvkgA4EIEkI1vuF3GyWEbaBcpaz6I0N7hhG pdf9LKahB2wCMaoek5BAVBwLx8Rgq/H1a4WgDfY31ckTddSIkIKcwKBnYSAVKYq0KkfB 2/uSCcOai2Cuol0HCJGBKhDaGRaBuPfcUSCRZQfW5JFoPwkTdi7sg8Y7dsgyERgTPjtt YEj/IvnwpuWu3ejhh3ijITDJXz0J/4eGbWQn2Rmnwu3JzJUrO1Pogc9RRAzTh3l9nxIe kwiQ== 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=HLhN9RFu9lLBh91C0UtWEhSEpP5/7mxewMk7n2SRYqo=; b=W4U8QXlAndiA4XQqE2SLXdhVf/ZdRRBdaucpO6DZoOuTsq05nbsxDrKydiUM1nfWcQ PxkatWW7eqbEqxaqEKfGME8sJjMeQwmxguKU7zRfHSbXhfLcDFioKj6wCr82XnxoA6UJ /93De2aQhsWnbyrY7Vd7d9ajbcxP3a36lSi0yAI46vGhBnOxuSidXUhBrUbzCCIU2Qav 3q/dzxiL8EhCYToNgf/v64lJllxY1EVWLhuWnjklF+H5AiOSdO8R5I/8QiRYJuh1sc6k 2/t7HJBMbubwRkacu61MLfm4jiipGJhdozxNceV7N7Loz/CflKj++CYljC3D1SGeSdUW 133g== X-Gm-Message-State: ACrzQf0KyxGy0yjf9SmDb0xuNDzAipUkHS9E2JxJjs7gHIC7v1YT/E0N nY052O/L26GruCedzjNIhxG/V2jn2SHvgIAzrv4= X-Google-Smtp-Source: AMsMyM7kXpSfh5vYrWgCKxtJUf3iqZZNbn7U3YVDwuL+qIEaCcfisIgbHInB/2477lIEWKsQIMP/KomrJDAMTRNLKz0= X-Received: by 2002:a63:d757:0:b0:46f:9446:273d with SMTP id w23-20020a63d757000000b0046f9446273dmr19336230pgi.436.1667410579598; Wed, 02 Nov 2022 10:36:19 -0700 (PDT) MIME-Version: 1.0 References: <20221031183122.470962-1-shy828301@gmail.com> In-Reply-To: From: Yang Shi Date: Wed, 2 Nov 2022 10:36:07 -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; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=TCPbdfHF; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.210.176 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=1667410580; a=rsa-sha256; cv=none; b=q829TtFaiNEZvwxWLT3m8GJ4X6QstWHXcLjpb8TOa5Q3NBKgyyvSqXNa5cu83/Xniyaekx moskhuvuVMw8KEfcFNaVLxxEMuvoAz/fZ5jMcilLUZCTsCWWD+qSQN3LAwQpO+739l0IfI copNy0BBzpB5BOOc6ZRvlJZWZsxi6yI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667410580; 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=HLhN9RFu9lLBh91C0UtWEhSEpP5/7mxewMk7n2SRYqo=; b=DDx+GO7dhDcKZBikCxUxZloBnXdtNFGoABLborv16lq1jZEhqHzJltrJsbjDZ4lDv4Cu+x cy+2EYEIiYqSwyK7HMBkSy5YKrMx7vD+ORnuvLcj7RItQ9mzCnnA2agpK9wLTUblm8h6wn eH28Sjc//gr5dPmCWtls43ocSuVG0us= X-Stat-Signature: sdiytb1nd7pdw4ohrb1491jrik3zc7xx X-Rspamd-Queue-Id: B3D0840007 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=TCPbdfHF; spf=pass (imf04.hostedemail.com: domain of shy828301@gmail.com designates 209.85.210.176 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: 1667410580-811549 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 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? > -- > Michal Hocko > SUSE Labs