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 0775EC433F5 for ; Mon, 6 Dec 2021 14:21:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 712586B006C; Mon, 6 Dec 2021 09:21:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C1EE6B007D; Mon, 6 Dec 2021 09:21:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58A106B007E; Mon, 6 Dec 2021 09:21:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay029.a.hostedemail.com [64.99.140.29]) by kanga.kvack.org (Postfix) with ESMTP id 481A66B006C for ; Mon, 6 Dec 2021 09:21:18 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F3B41207AA for ; Mon, 6 Dec 2021 14:21:07 +0000 (UTC) X-FDA: 78887581374.01.D19BDA1 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf01.hostedemail.com (Postfix) with ESMTP id 848F540007 for ; Mon, 6 Dec 2021 14:21:07 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 6F58F1FD54; Mon, 6 Dec 2021 14:21:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1638800466; 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=AU1DxmYfAhM8Rnmo8sN6ucgP0navAddPsgho6J/htyo=; b=VnKCwTuRMfprOOmZG4Fk4Bmu2C/b0yIKtekgS7lJU+W8noBnINV02QAh7//iJJo1sKpdNk 7yQEx5wI+9VLUCZp2TcU1LEoiZslBDWbuyGugan2ztTjXtNOuc+E2jKHjeHPnq9xWWnqrK QUbW/CHBkuhBhJGpY613SlMNaOvA86o= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 3E17FA3B81; Mon, 6 Dec 2021 14:21:06 +0000 (UTC) Date: Mon, 6 Dec 2021 15:21:05 +0100 From: Michal Hocko To: David Hildenbrand Cc: Nico Pache , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, shakeelb@google.com, ktkhai@virtuozzo.com, shy828301@gmail.com, guro@fb.com, vbabka@suse.cz, vdavydov.dev@gmail.com, raquini@redhat.com Subject: Re: [RFC PATCH 2/2] mm/vmscan.c: Prevent allocating shrinker_info on offlined nodes Message-ID: References: <840cb3d0-61fe-b6cb-9918-69146ba06cf7@redhat.com> <51c65635-1dae-6ba4-daf9-db9df0ec35d8@redhat.com> <05157de4-e5df-11fc-fc46-8a9f79d0ddb4@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: ebur1h3s7iwiw17pmfwetdtoy43cethj Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=VnKCwTuR; spf=pass (imf01.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 848F540007 X-HE-Tag: 1638800467-721657 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 Mon 06-12-21 15:08:10, David Hildenbrand wrote: > > >> But there might be more missing. Onlining a new zone will get more > >> expensive in setups with a lot of possible nodes (x86-64 shouldn't > >> really be an issue in that regard). > > > > Honestly, I am not really concerned by platforms with too many nodes > > without any memory. If they want to shoot their feet then that's their > > choice. We can optimize for those if they ever prove to be standar. > > > >> If we want stable backports, we'll want something simple upfront. > > > > For stable backports I would be fine by doing your NODE_DATA check in > > the allocator. In upstream I think we should be aiming for a more robust > > solution that is also easier to maintain further down the line. Even if > > that is an investment at this momemnt because the initialization code is > > a mess. > > > > Agreed. I would be curious *why* we decided to dynamically allocate the > pgdat. is this just a historical coincidence or was there real reason to > not allocate it for all possible nodes during boot? I don't know but if I was to guess the most likely explanation would be that the numa init code was in a similar order as now and it was easier to simply allocate a pgdat when a new one was onlined. 9af3c2dea3a3 ("[PATCH] pgdat allocation for new node add (call pgdat allocation)") doesn't really tell much. -- Michal Hocko SUSE Labs