Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp3584606iob; Tue, 17 May 2022 03:15:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJybW5KZ9MhPB9a/syw2kHrWf0zGGmuMnXu4Ce7UEKCWxcB2QqNOI98UUI/Cvf12+Yd2G7U1 X-Received: by 2002:a05:6a00:1683:b0:4f7:e497:6a55 with SMTP id k3-20020a056a00168300b004f7e4976a55mr21575968pfc.21.1652782527808; Tue, 17 May 2022 03:15:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652782527; cv=none; d=google.com; s=arc-20160816; b=peMuNNrMyzgb3w1a1egCzEnaixsGhi/25Y9aIVIwZdm7j0a0WbOdm5ptNgUB/JXcVl yeluCKt22JEiVMdr8wgrDOqbluG9qjeF1K8EpEw8SnWkE1tjySZ0Wt8rewWH4cAgXlEm 2YA/kNlAGKcaqAV3VPbsTzOIbEFb+cZGXjpwuiIcuvZMDvAkWicC/sz1TVEcSONYtLK1 gvYCajsAFZlaEoKiFzrM0YaTqDrHzVZMamrq6BNF9+fD4xmLtdM3b0bdI5hvo9w22ZeK 6vQffDu0oRrVUd3i5h7mpNcpVf7H1yXzNGSB4ntE+L7UlNPjo4xN7u9AZt57lX/X1kVJ c73A== 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 :dkim-signature; bh=ghycn6t5xJ3FJyT4xCbUwPxtWo84lq0XciIN7RNaQPw=; b=IZSmDpzzA7cJWqGq6R8IwMzDHg7GePC6XBzHe+US7AKXWpWyI6MoxpmL4ClV6FErw1 4GtE+vc8jSR+LhENhTIm8fh7pTvB5CTqz6ZCULbTyUCg2/3V/0y1WOp9rZbE9ano+quQ 4wbWMAYpWH9NMOBVleoO0MoftXuA3VYxf8JZ7UEXZxq2f6AsPvXnrUBBZdI6CFZuEjv8 4cvlJaD2SooesYt3qi485/HRGlQB8XFQjoR3bTjZyaO/AZTUsx8fpdWx2dic8Gi4UsRE 7WMaK3KLztXi9K9vaD2tqtygO+V1sPdqlAhUQAIyAsR3K0p/vuD/Tk2rKPwcuvmAQA4o PuTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=i868hRhn; dkim=neutral (no key) header.i=@suse.de header.b=Q9pVjJen; 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=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o8-20020a17090a9f8800b001c62fca7148si2122936pjp.170.2022.05.17.03.15.16; Tue, 17 May 2022 03:15:27 -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.de header.s=susede2_rsa header.b=i868hRhn; dkim=neutral (no key) header.i=@suse.de header.b=Q9pVjJen; 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=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231911AbiEQHsA (ORCPT + 99 others); Tue, 17 May 2022 03:48:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229797AbiEQHr4 (ORCPT ); Tue, 17 May 2022 03:47:56 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 486242ED76; Tue, 17 May 2022 00:47:53 -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 D2EE51F383; Tue, 17 May 2022 07:47:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1652773671; 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=ghycn6t5xJ3FJyT4xCbUwPxtWo84lq0XciIN7RNaQPw=; b=i868hRhnCUZBdkwQJa44Asp8b1Nc0V/TynvKKK44LKL3NafC+P3RNwyXMfDY3KbBG+R/Na QdJYGCO+I4wuL88+HbcyfHGK2GjIZhYTN7K/FceKkrk0akPVhVfISw3W42ziV+/uv2tpu8 brVz8X3/ql+x4n1JTJm778CHu2zXdBY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1652773671; 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=ghycn6t5xJ3FJyT4xCbUwPxtWo84lq0XciIN7RNaQPw=; b=Q9pVjJenIkTEi5h+JnIgeYZNGJuWpAXJulbLyZhBh6PUEVTplPxsxls8rVimwa1DseFClU x/giIQLPPpKrznAg== 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 391BD13305; Tue, 17 May 2022 07:47:50 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id xvtrCiZTg2ILfwAAMHmgww (envelope-from ); Tue, 17 May 2022 07:47:50 +0000 Date: Tue, 17 May 2022 09:47:48 +0200 From: Oscar Salvador To: Muchun Song Cc: corbet@lwn.net, mike.kravetz@oracle.com, akpm@linux-foundation.org, mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, david@redhat.com, masahiroy@kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, duanxiongchun@bytedance.com, smuchun@gmail.com Subject: Re: [PATCH v12 3/7] mm: memory_hotplug: enumerate all supported section flags Message-ID: References: <20220516102211.41557-1-songmuchun@bytedance.com> <20220516102211.41557-4-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220516102211.41557-4-songmuchun@bytedance.com> 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,T_SCC_BODY_TEXT_LINE 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 Mon, May 16, 2022 at 06:22:07PM +0800, Muchun Song wrote: > We are almost running out of free slots, only one bit is available in the I would be more precise about what are we running out of. Free slots of what? > worst case (powerpc with 256k pages). However, there are still some free > slots on other architectures (e.g. x86_64 has 10 bits available, arm64 > has 8 bits available with worst case of 64K pages). We have hard coded > those numbers in code, it is inconvenient to use those bits on other > architectures except powerpc. So transfer those section flags to > enumeration to make it easy to add new section flags in the future. Also, > move SECTION_TAINT_ZONE_DEVICE into the scope of CONFIG_ZONE_DEVICE > to save a bit on non-zone-device case. > > Signed-off-by: Muchun Song > --- ... > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -1418,16 +1418,37 @@ extern size_t mem_section_usage_size(void); > * (equal SECTION_SIZE_BITS - PAGE_SHIFT), and the > * worst combination is powerpc with 256k pages, > * which results in PFN_SECTION_SHIFT equal 6. > - * To sum it up, at least 6 bits are available. > + * To sum it up, at least 6 bits are available on all architectures. > + * However, we can exceed 6 bits on some other architectures except > + * powerpc (e.g. 15 bits are available on x86_64, 13 bits are available > + * with the worst case of 64K pages on arm64) if we make sure the > + * exceeded bit is not applicable to powerpc. > */ > -#define SECTION_MARKED_PRESENT (1UL<<0) > -#define SECTION_HAS_MEM_MAP (1UL<<1) > -#define SECTION_IS_ONLINE (1UL<<2) > -#define SECTION_IS_EARLY (1UL<<3) > -#define SECTION_TAINT_ZONE_DEVICE (1UL<<4) > -#define SECTION_MAP_LAST_BIT (1UL<<5) > +#define ENUM_SECTION_FLAG(MAPPER) \ > + MAPPER(MARKED_PRESENT) \ > + MAPPER(HAS_MEM_MAP) \ > + MAPPER(IS_ONLINE) \ > + MAPPER(IS_EARLY) \ > + MAPPER(TAINT_ZONE_DEVICE, CONFIG_ZONE_DEVICE) \ > + MAPPER(MAP_LAST_BIT) > + > +#define __SECTION_SHIFT_FLAG_MAPPER_0(x) > +#define __SECTION_SHIFT_FLAG_MAPPER_1(x) SECTION_##x##_SHIFT, > +#define __SECTION_SHIFT_FLAG_MAPPER(x, ...) \ > + __PASTE(__SECTION_SHIFT_FLAG_MAPPER_, IS_ENABLED(__VA_ARGS__))(x) > + > +#define __SECTION_FLAG_MAPPER_0(x) > +#define __SECTION_FLAG_MAPPER_1(x) SECTION_##x = BIT(SECTION_##x##_SHIFT), > +#define __SECTION_FLAG_MAPPER(x, ...) \ > + __PASTE(__SECTION_FLAG_MAPPER_, IS_ENABLED(__VA_ARGS__))(x) > + > +enum { > + ENUM_SECTION_FLAG(__SECTION_SHIFT_FLAG_MAPPER) > + ENUM_SECTION_FLAG(__SECTION_FLAG_MAPPER) > +}; > + > #define SECTION_MAP_MASK (~(SECTION_MAP_LAST_BIT-1)) > -#define SECTION_NID_SHIFT 6 > +#define SECTION_NID_SHIFT SECTION_MAP_LAST_BIT_SHIFT Is this really worth the extra code? And it might be me that I am not familiar with all this magic, but it looks overcomplicated. Maybe some comments here and there help clarifying what it is going on here. > static inline struct page *__section_mem_map_addr(struct mem_section *section) > { > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index 111684878fd9..aef3f041dec7 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -655,12 +655,18 @@ static void __meminit resize_pgdat_range(struct pglist_data *pgdat, unsigned lon > > } > > +#ifdef CONFIG_ZONE_DEVICE > static void section_taint_zone_device(unsigned long pfn) > { > struct mem_section *ms = __pfn_to_section(pfn); > > ms->section_mem_map |= SECTION_TAINT_ZONE_DEVICE; > } > +#else > +static inline void section_taint_zone_device(unsigned long pfn) > +{ > +} > +#endif > > /* > * Associate the pfn range with the given zone, initializing the memmaps > -- > 2.11.0 > > -- Oscar Salvador SUSE Labs