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 X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3981DC47080 for ; Tue, 1 Jun 2021 08:46:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DB32261396 for ; Tue, 1 Jun 2021 08:46:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DB32261396 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 76A926B009D; Tue, 1 Jun 2021 04:46:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 743466B009E; Tue, 1 Jun 2021 04:46:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56D3C6B009F; Tue, 1 Jun 2021 04:46:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id 20B596B009D for ; Tue, 1 Jun 2021 04:46:02 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 91FAB181AC9CB for ; Tue, 1 Jun 2021 08:46:01 +0000 (UTC) X-FDA: 78204522522.17.4FF7BDB Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by imf08.hostedemail.com (Postfix) with ESMTP id 6F75B8019365 for ; Tue, 1 Jun 2021 08:45:49 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id 69-20020a9d0a4b0000b02902ed42f141e1so13456085otg.2 for ; Tue, 01 Jun 2021 01:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fvnZa/3GSWoijoWUP996Kg50ie5gi3CPyJfodx+nuj0=; b=Nm5Z+r3e6oXn/WlBAHuSatC+Zo4ChEuTrkW4GYAtxAnuTcS8ijCh9zciZfzaGMAbLe HwZZVgOp01U37i19k0ig3zBH8zqT5saOozaec5th3B00AAtDQW7NBV+yO63SGWAgaH6q ZzpIVmIYvlhwKNY884ZMyaqFTyErDAWoGe4gUkYRRmCwm9cxwknSHzfofDMd2mT3HcBQ Bb4+Yt/9ua1LM6uaoDAkno+wfqN9ryawjaBoDzwCWBKx3Scri/hH+hLnAhtyA+3SoAcV QR+yzBKTe/qJy9Iz1+vBG8Hquz4NeCqN5wz0YWIsW8m7mBLlS3WLsiLeg3uq5f2jfK41 HqeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fvnZa/3GSWoijoWUP996Kg50ie5gi3CPyJfodx+nuj0=; b=G0w5HPKNSQLFHdMCyNl9f4Cjd319L8LzoYfI38MvX+rQZG0KTnEHBMTAItBUIyzlkt 8EHGFASDvVWyb+4qzQgjnQksYKdp38iEmIVMpHPSoaQcnoOwybTHL9gzgNzWJIR9uUQf bTBBV1qDEc5HciWM97vInj1FLb+tTFcwQbD9P4OgA5ciFpMOI1gS78cpSxeirDueab54 lBAGRMs8BE3aTPK+H/xgeBZKpIpvrMFHbJCvwq1fj5aPxo/iOhDdrPLDl37IYYk/LnhY AAGvOk81ZpE/6wnU63Y2B50Su+MnSVAHnrX2ZSbd+6EembHQQ/9qgJF+4PyR8L4neGqF kRkw== X-Gm-Message-State: AOAM531rs4Kr4j9NmshyI6xOn7nEVZFb/gD7ZZCQFDIovlJWAKr+n9Ku 28qrW7D48deJpjtjEyz1+Je8vg4UVWoVcnc4MTI= X-Google-Smtp-Source: ABdhPJyFMV+qnkun3wPnfMnzQCAc/g3cwnJpVtSi+3/UR2QQDOtEF6tNOzyRVc8MK481WPpd5qi/KUtmK8FX72qE3uQ= X-Received: by 2002:a9d:4115:: with SMTP id o21mr20597434ote.52.1622537160686; Tue, 01 Jun 2021 01:46:00 -0700 (PDT) MIME-Version: 1.0 References: <20210531091908.1738465-1-aisheng.dong@nxp.com> <20210531091908.1738465-5-aisheng.dong@nxp.com> <42617372-c846-85fe-4739-abbe55eca8f6@redhat.com> In-Reply-To: From: Dong Aisheng Date: Tue, 1 Jun 2021 16:44:50 +0800 Message-ID: Subject: Re: [PATCH V2 4/6] mm: rename the global section array to mem_sections To: David Hildenbrand Cc: Dong Aisheng , linux-mm@kvack.org, open list , Andrew Morton , Dave Young , Baoquan He , Vivek Goyal , kexec@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=Nm5Z+r3e; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of dongas86@gmail.com designates 209.85.210.50 as permitted sender) smtp.mailfrom=dongas86@gmail.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6F75B8019365 X-Stat-Signature: g1dnqrnqfdya3t49uzmsowf5y7cq6sok X-HE-Tag: 1622537149-474666 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 1, 2021 at 4:40 PM David Hildenbrand wrote: > > On 01.06.21 10:37, Dong Aisheng wrote: > > On Tue, Jun 1, 2021 at 4:22 PM David Hildenbrand wrote: > >> > >> On 31.05.21 11:19, Dong Aisheng wrote: > >>> In order to distinguish the struct mem_section for a better code > >>> readability and align with kernel doc [1] name below, change the > >>> global mem section name to 'mem_sections' from 'mem_section'. > >>> > >>> [1] Documentation/vm/memory-model.rst > >>> "The `mem_section` objects are arranged in a two-dimensional array > >>> called `mem_sections`." > >>> > >>> Cc: Andrew Morton > >>> Cc: Dave Young > >>> Cc: Baoquan He > >>> Cc: Vivek Goyal > >>> Cc: kexec@lists.infradead.org > >>> Signed-off-by: Dong Aisheng > >>> --- > >>> v1->v2: > >>> * no changes > >>> --- > >>> include/linux/mmzone.h | 10 +++++----- > >>> kernel/crash_core.c | 4 ++-- > >>> mm/sparse.c | 16 ++++++++-------- > >>> 3 files changed, 15 insertions(+), 15 deletions(-) > >>> > >>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > >>> index a6bfde85ddb0..0ed61f32d898 100644 > >>> --- a/include/linux/mmzone.h > >>> +++ b/include/linux/mmzone.h > >>> @@ -1302,9 +1302,9 @@ struct mem_section { > >>> #define SECTION_ROOT_MASK (SECTIONS_PER_ROOT - 1) > >>> > >>> #ifdef CONFIG_SPARSEMEM_EXTREME > >>> -extern struct mem_section **mem_section; > >>> +extern struct mem_section **mem_sections; > >>> #else > >>> -extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; > >>> +extern struct mem_section mem_sections[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; > >>> #endif > >>> > >>> static inline unsigned long *section_to_usemap(struct mem_section *ms) > >>> @@ -1315,12 +1315,12 @@ static inline unsigned long *section_to_usemap(struct mem_section *ms) > >>> static inline struct mem_section *__nr_to_section(unsigned long nr) > >>> { > >>> #ifdef CONFIG_SPARSEMEM_EXTREME > >>> - if (!mem_section) > >>> + if (!mem_sections) > >>> return NULL; > >>> #endif > >>> - if (!mem_section[SECTION_NR_TO_ROOT(nr)]) > >>> + if (!mem_sections[SECTION_NR_TO_ROOT(nr)]) > >>> return NULL; > >>> - return &mem_section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; > >>> + return &mem_sections[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; > >>> } > >>> extern unsigned long __section_nr(struct mem_section *ms); > >>> extern size_t mem_section_usage_size(void); > >>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c > >>> index 29cc15398ee4..fb1180d81b5a 100644 > >>> --- a/kernel/crash_core.c > >>> +++ b/kernel/crash_core.c > >>> @@ -414,8 +414,8 @@ static int __init crash_save_vmcoreinfo_init(void) > >>> VMCOREINFO_SYMBOL(contig_page_data); > >>> #endif > >>> #ifdef CONFIG_SPARSEMEM > >>> - VMCOREINFO_SYMBOL_ARRAY(mem_section); > >>> - VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > >>> + VMCOREINFO_SYMBOL_ARRAY(mem_sections); > >>> + VMCOREINFO_LENGTH(mem_sections, NR_SECTION_ROOTS); > >>> VMCOREINFO_STRUCT_SIZE(mem_section); > >>> VMCOREINFO_OFFSET(mem_section, section_mem_map); > >>> VMCOREINFO_NUMBER(MAX_PHYSMEM_BITS); > >>> diff --git a/mm/sparse.c b/mm/sparse.c > >>> index d02ee6bb7cbc..6412010478f7 100644 > >>> --- a/mm/sparse.c > >>> +++ b/mm/sparse.c > >>> @@ -24,12 +24,12 @@ > >>> * 1) mem_section - memory sections, mem_map's for valid memory > >>> */ > >>> #ifdef CONFIG_SPARSEMEM_EXTREME > >>> -struct mem_section **mem_section; > >>> +struct mem_section **mem_sections; > >>> #else > >>> -struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] > >>> +struct mem_section mem_sections[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] > >>> ____cacheline_internodealigned_in_smp; > >>> #endif > >>> -EXPORT_SYMBOL(mem_section); > >>> +EXPORT_SYMBOL(mem_sections); > >>> > >>> #ifdef NODE_NOT_IN_PAGE_FLAGS > >>> /* > >>> @@ -66,8 +66,8 @@ static void __init sparse_alloc_section_roots(void) > >>> > >>> size = sizeof(struct mem_section *) * NR_SECTION_ROOTS; > >>> align = 1 << (INTERNODE_CACHE_SHIFT); > >>> - mem_section = memblock_alloc(size, align); > >>> - if (!mem_section) > >>> + mem_sections = memblock_alloc(size, align); > >>> + if (!mem_sections) > >>> panic("%s: Failed to allocate %lu bytes align=0x%lx\n", > >>> __func__, size, align); > >>> } > >>> @@ -103,14 +103,14 @@ static int __meminit sparse_index_init(unsigned long section_nr, int nid) > >>> * > >>> * The mem_hotplug_lock resolves the apparent race below. > >>> */ > >>> - if (mem_section[root]) > >>> + if (mem_sections[root]) > >>> return 0; > >>> > >>> section = sparse_index_alloc(nid); > >>> if (!section) > >>> return -ENOMEM; > >>> > >>> - mem_section[root] = section; > >>> + mem_sections[root] = section; > >>> > >>> return 0; > >>> } > >>> @@ -145,7 +145,7 @@ unsigned long __section_nr(struct mem_section *ms) > >>> #else > >>> unsigned long __section_nr(struct mem_section *ms) > >>> { > >>> - return (unsigned long)(ms - mem_section[0]); > >>> + return (unsigned long)(ms - mem_sections[0]); > >>> } > >>> #endif > >>> > >>> > >> > >> I repeat: unnecessary code churn IMHO. > > > > Hi David, > > > > Thanks, i explained the reason during my last reply. > > Andrew has already picked this patch to -mm tree. > > Just because it's in Andrews tree doesn't mean it will end up upstream. ;) > > Anyhow, no really strong opinion, it's simply unnecessary code churn > that makes bisecting harder without real value IMHO. In my practice, it helps improve the code reading efficiency with scope and vim hotkey. Before the change, I really feel mixed definition causes troubles in reading code efficiently. Anyway, that's my personal experience while others may have different options. Thanks for the feedback. Regards Aisheng > > -- > Thanks, > > David / dhildenb >