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 3830CC433EF for ; Wed, 22 Jun 2022 04:25:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 951718E006E; Wed, 22 Jun 2022 00:25:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 900576B00A4; Wed, 22 Jun 2022 00:25:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A16C8E006E; Wed, 22 Jun 2022 00:25:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 674C26B00A2 for ; Wed, 22 Jun 2022 00:25:45 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2CFE86129F for ; Wed, 22 Jun 2022 04:25:42 +0000 (UTC) X-FDA: 79604583324.22.79C4DAC Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf24.hostedemail.com (Postfix) with ESMTP id 68368180029 for ; Wed, 22 Jun 2022 04:25:36 +0000 (UTC) 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-out1.suse.de (Postfix) with ESMTPS id A370921BB7; Wed, 22 Jun 2022 04:25:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1655871923; 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=WhHc108fd7a+OpnxW6vdJErjSH8L6j2zIy6yafQpOuM=; b=ZQ2x/Tx/YElTMBy9pLFeqUOLty6NnYiNC6AzvED+VQ532vEv6+6VLLadBygvyxWbGkridj W9Rhtvl979GhJs66T+QNXgv+gR5vDsSrNqtAjKA7OmAnU8zhHwZump1QdPdHE/95pHeAwo +KPaJ7Gmn784p/s8rIYl6USwy8IvUZE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1655871923; 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=WhHc108fd7a+OpnxW6vdJErjSH8L6j2zIy6yafQpOuM=; b=GNlk8wUlrvezFLFpuC5SQdGioW2Gz8JiODR/R8X7SETfaEZjxb/X6GTXWRhJhDhz9ktGNk vC35V3/9cWNgX6BA== 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 49265134A9; Wed, 22 Jun 2022 04:25:23 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id o/j6DrOZsmJjHQAAMHmgww (envelope-from ); Wed, 22 Jun 2022 04:25:23 +0000 Date: Wed, 22 Jun 2022 06:25:21 +0200 From: Oscar Salvador To: David Hildenbrand Cc: Andrew Morton , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] mm/memory_hotplug: Reset node's state when empty during offline Message-ID: References: <20220621041717.6355-1-osalvador@suse.de> <20220621041717.6355-3-osalvador@suse.de> <139fc140-142f-c467-a5e3-0a0954dca127@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <139fc140-142f-c467-a5e3-0a0954dca127@redhat.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655871937; a=rsa-sha256; cv=none; b=e5rBbmYOiJg4XcwMNfsK6evku5fPWG5/Kb7cZQAWzqfzZEV4rNjwP3SjPnmiEKNKLt3J/v dCWMyzUAxebMF+Eat8yVcU3hC/pSZjYpJ0FikPjF18oX6M91NI2LhdkoJCyisN8BzjeI0s xUiiL3hJXU5+t1NyfgxoDNvAkx50JPg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655871937; 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=WhHc108fd7a+OpnxW6vdJErjSH8L6j2zIy6yafQpOuM=; b=RN9XUnSmcWqduppE48HdMHgQoK9dZML5hJ2ihgBJ8eBdBu/X0BhezMmgsmif/RujtiGWGF pkgSojlOGA2eXqayaoGOfXeuUkQTRdDSVqBwZ0ZkKTVRWHrMpVHJLaRgjX2NiB8ZP8K9O3 NQbYOOZEWpvpTR/wrMfx9Lskag1YYxM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="ZQ2x/Tx/"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=GNlk8wUl; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf24.hostedemail.com: domain of osalvador@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=osalvador@suse.de X-Rspam-User: X-Rspamd-Queue-Id: 68368180029 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="ZQ2x/Tx/"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=GNlk8wUl; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf24.hostedemail.com: domain of osalvador@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=osalvador@suse.de X-Stat-Signature: h4xdqwykjseakj9kdwa6xz19tjbrupq7 X-Rspamd-Server: rspam09 X-HE-Tag: 1655871936-638766 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 Tue, Jun 21, 2022 at 09:59:07AM +0200, David Hildenbrand wrote: > > +static void node_reset_state(int node) > > +{ > > + pg_data_t *pgdat = NODE_DATA(node); > > + int cpu; > > + > > + kswapd_stop(node); > > + kcompactd_stop(node); > > + > > + pgdat->nr_zones = 0; > > ^ what is that? it should be "highest_zone_idx" and I don't see any > reason that we really need this. Uhm, I thought we need to reset this, otherwise init_currently_empty_zone() might not set it to a right value: ... if (zone_idx > pgdat->nr_zones) pgdat->nr_zones = zone_idx ... At least we set it to 0 in free_area_init_core_hotplug() (before this patch). > To detect if a node is empty we can use pgdat_is_empty(). To detect if a > zone is empty we can use zone_is_empty(). > > The usage of "pgdat->nr_zones" as an optimization is questionable, > especially when iterating over our handful of zones where most nodes > miss the *lower* zones like ZONE_DMA* in practice and have ZONE_NORMAL. > > Can we get rid of that and just check pgdat_is_empty() and > zone_is_empty() and iterate all applicable zones from 0..X? So, lemme see if I get you. You mean to e.g: replace the following (code snippet from set_pgdat_percpu_threshold) for (i = 0; i < pgdat->nr_zones; i++) { zone = &pgdat->node_zones[i]; [some code] } with this: for (zid = 0; zid < MAX_NR_ZONES; i++) { struct zone *zone = pgdat->node_zones + i; if (zone_is_empty(zone)) continue; } I guess we can, and I can see that we have a mix of both usages, so it might be good to consolidate one. And actually, I think we do the same amount of work, right? So not really an optimization in those pieces of code. The only thing that unsettles me is the compaction part. We set pgdat->kcompactd_highest_zoneidx by checking pgdat->nr_zones, and use that as our compact_control->highest_zoneidx. (kcompactd->kcompactd_do_work) Now, I do not really see any reason we could not adapt that code to not realy on pgdat->nr_zones, but I would have to check further how this interacts with highest_zoneidx down the road, and where else should we rewrite code. -- Oscar Salvador SUSE Labs