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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0A2EC433F5 for ; Tue, 7 Dec 2021 10:15:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234423AbhLGKSs (ORCPT ); Tue, 7 Dec 2021 05:18:48 -0500 Received: from smtp-out1.suse.de ([195.135.220.28]:44590 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234933AbhLGKSp (ORCPT ); Tue, 7 Dec 2021 05:18:45 -0500 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id BDF9421B3E; Tue, 7 Dec 2021 10:15:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1638872114; 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=fmiDXA5yzuOQ3TCOggxW4h5cLqZY2pHWb0txkt/F/pc=; b=IqW/fQHgB6cUG7JdfpLS9iXvR+Oo1okV83ZgupHdvpn+I+hcJpKHI6aU7od55aKm5f943N WV+Lz1y4Cyl/phAHHe7GPybOaW8UpTgXZy274rmRPmQxWRQd3m2FzMGDlLTCQJxIzMhWkC hEgoxQ5Obmjc4x9qiXaBff6qKdJHDXI= 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 7BAE5A3B8B; Tue, 7 Dec 2021 10:15:14 +0000 (UTC) Date: Tue, 7 Dec 2021 11:15:13 +0100 From: Michal Hocko To: Yang Shi Cc: Vlastimil Babka , David Hildenbrand , Nico Pache , Linux Kernel Mailing List , Linux MM , Andrew Morton , Shakeel Butt , Kirill Tkhai , Roman Gushchin , Vladimir Davydov , raquini@redhat.com Subject: Re: [RFC PATCH 2/2] mm/vmscan.c: Prevent allocating shrinker_info on offlined nodes Message-ID: References: <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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 06-12-21 10:26:32, Yang Shi wrote: [...] > But IMHO actually the memory usage should be not that bad for memcg > heavy usecases since there should be not too many "never onlined" > nodes for such workloads? Hardware with very sparse nodes topology are really scarce. More likely on ppc (LPARs) but even then we are talking about really low number of nodes. At least this is my experience. So while the memory wasting is possible it doesn't seem to be a really pressing problem. I would be more careful about a code which scales with MAX_NUMNODES because that can be really large. -- Michal Hocko SUSE Labs