Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp210784rwi; Wed, 2 Nov 2022 11:02:14 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4QMyrwS4GffNkud9d/31jy/nBUFd5y/WRg4S9LgkbJZZlGKdxHvBjg995uErK1lSx5+hI1 X-Received: by 2002:a17:907:97d6:b0:7ad:b962:33e8 with SMTP id js22-20020a17090797d600b007adb96233e8mr23014441ejc.27.1667412134218; Wed, 02 Nov 2022 11:02:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667412134; cv=none; d=google.com; s=arc-20160816; b=DT8Whm0b9ftRTnXxZEGH/mVLhX3VQWP3oTiCSTx09J6F1Oeh0oh32XWqGhWqkc34Yg E8Hkx/EXE4qeIWr1KcSXfmoHzcaONTd7b7i2jVALEZqWWsDHYqa0cek0yHkHm19TGyl4 bOMF69xcHN2QmeI2ET/F3YdVxsGRUaDmwQ5W3P4Rj12lxqwjURKY9caVtCQPqGDa+dlr p29Ue+Pc0RcffEa8qZjlfWH0L/i/8IGcE8B7q50hUct/QP3tPHqJNOIGdA55y6aDsJFD IsJIicNoMV/aQRT5vI7Af3zKYJTaWH9PCq7aTwQn2lRhxqPaItsyMXz2AnztDmazH0vu gmzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=bIXibXXjjmnVVHx6xjVFUipVPFmWAiVSbZzEqPxgGqU=; b=Iuw/eAvSP80SHiD24GN/tmg8oJY5E4vjUuvtFA6Z7yyKK3Db3KOj5WGLquomNsOLlm acvYUsAUH6VvZZYsKxi8hzgGW2e3DH0nV8K0NnOjhuCf7oTYw7YXYJknU67oUSSepOh7 /oMEnWj+1uJsULgPWsb53nofwLLCgeZhRAt9uhQmj4DwJ8PLG4v55vfJYPEzVhPG1QIq Lk+f7/bZAs7rVITWhBLSoZJnl5kjxAneikUGY1cT/Aqw86sOsvb9y2ghTYSk5gI+IfEc CNa9kq48FHEg1tc9kv2Id8ZmNbM7Bs3S6GnEVtS250Xb5kmdiw/AdvifRaEF4vibpc8h qL0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=gIsTGpGg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dt19-20020a170907729300b0073da4a0f01csi17904850ejc.743.2022.11.02.11.01.21; Wed, 02 Nov 2022 11:02:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=gIsTGpGg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231434AbiKBRrd (ORCPT + 98 others); Wed, 2 Nov 2022 13:47:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46436 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231579AbiKBRrZ (ORCPT ); Wed, 2 Nov 2022 13:47:25 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9845927B18 for ; Wed, 2 Nov 2022 10:47:23 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 4B48E1F855; Wed, 2 Nov 2022 17:47:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1667411242; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bIXibXXjjmnVVHx6xjVFUipVPFmWAiVSbZzEqPxgGqU=; b=gIsTGpGgO0MrSHOFFGoAwL+viqPrxOnfGXqwBcdrDNOz2aiMyvX2X8419Cvfk6GWPGoJB5 4mQ8qcsOKYh6eF3aAb36+YLp1iq5ueprzeCyLwRpHHa8LEezhpAVTTS1aLnc+19TdlZ+lT CfQWH4wz9OsbO9obcDsQtc+EpgcMwQ8= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 3089A139D3; Wed, 2 Nov 2022 17:47:22 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id e3wLCiqtYmMKSQAAMHmgww (envelope-from ); Wed, 02 Nov 2022 17:47:22 +0000 Date: Wed, 2 Nov 2022 18:47:21 +0100 From: Michal Hocko To: Yang Shi Cc: Zach O'Keefe , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: don't warn if the node is offlined Message-ID: References: <20221031183122.470962-1-shy828301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. And as mentioned in other reply it would be really nice to hide this under CONFIG_NUMA (in a standalong follow up of course). -- Michal Hocko SUSE Labs