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 F2F95C433EF for ; Tue, 17 May 2022 08:10:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E1456B0072; Tue, 17 May 2022 04:10:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 890106B0073; Tue, 17 May 2022 04:10:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77EC16B0074; Tue, 17 May 2022 04:10:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 695FD6B0072 for ; Tue, 17 May 2022 04:10:26 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 43C4D31067 for ; Tue, 17 May 2022 08:10:26 +0000 (UTC) X-FDA: 79474512852.21.AC7A5DE Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) by imf22.hostedemail.com (Postfix) with ESMTP id 267BBC0057 for ; Tue, 17 May 2022 08:10:22 +0000 (UTC) Received: by mail-pj1-f43.google.com with SMTP id nr2-20020a17090b240200b001df2b1bfc40so1696145pjb.5 for ; Tue, 17 May 2022 01:10:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=CXzcoF7uGQa7GHZsoGZF5yhHmI1X2MWtHl4LQhGP75I=; b=uxzHIswcUIBZjJjtgwN8EZvrVmcOw1mvBk3nZIj3ytVkC/DJX39aOVXFUmMR1pzvrD MwVpKjHY+vD0HkINX4zDunv46HZwmZeiEgK72lOssnPMkv39GgXdrkTG1B6CXRQn0fre C/lzNiijUh1ASi8Sou3AoO6nxZX6IgVqKNgtKrq4AqV1BiKPuAOu99AJI0SN4/oaED/6 k/5lEDLzfyVgJdkB2IKunNt1Y1NxoEU7a2eJamggcAGRk1Zi3gHoWXFu50SyI+YI/UyF RZLxdXzYPXavqQrosZAIik9wjJcEEYrtqotkz575IA3HKImjMxhi7h/IehlEU5t3xnkO Qs5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CXzcoF7uGQa7GHZsoGZF5yhHmI1X2MWtHl4LQhGP75I=; b=znL5wpIEvCsgNfrVA1khylBE6z76EtShg82dfS0XHYJZ/D0aNgIZiMGzliq383rhRV hCcDjOBY9QiSZv8CF0t8ZTXAVh+mJcZX2E7Q3+9sqG0M/IW1DbWoia9pPGJjV0gYALrH xROjubnV50gEJUOKoxh+LQs7pfO6VTK0y+hpTf8rBLpvGY3ExvBVyN19kXekQvXW3hrH BV/XHIPyrAn60b8B15fjXyZF6YBix3C2gLc3F0VcsgkDCkV2n7jylP2eEJ6qBvi58ZUi RQI1eLBpkcz40VCSuZEEPYBAGz19M3mgiqRqUPrPEXsrOO4qjTuWSeeAkSlgE3SH2tvG DDCQ== X-Gm-Message-State: AOAM532970i5DF1F1wqxE17JX7ta/v6gYos4udQSLPyx7mscH/nCtLHC ytMiHpxGKldSp8xbaqx/lklDkA== X-Google-Smtp-Source: ABdhPJzQiIHxbzey1EBFjyDjrpOLNbUL2EEf7wQ5kLnpJUVSAqcTqPkFIcf7jRVxmo1/O44Wql6QUA== X-Received: by 2002:a17:903:40d2:b0:161:a2d9:3230 with SMTP id t18-20020a17090340d200b00161a2d93230mr2911147pld.57.1652775023946; Tue, 17 May 2022 01:10:23 -0700 (PDT) Received: from localhost ([139.177.225.250]) by smtp.gmail.com with ESMTPSA id m24-20020a62a218000000b005107da0f34csm8149530pff.20.2022.05.17.01.10.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 May 2022 01:10:23 -0700 (PDT) Date: Tue, 17 May 2022 16:10:20 +0800 From: Muchun Song To: Oscar Salvador 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 4/7] mm: hotplug: introduce SECTION_CANNOT_OPTIMIZE_VMEMMAP Message-ID: References: <20220516102211.41557-1-songmuchun@bytedance.com> <20220516102211.41557-5-songmuchun@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: gue1iugzrspprheengh3hn5ts4ng8z4i X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 267BBC0057 X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=uxzHIswc; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf22.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.216.43 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-HE-Tag: 1652775022-531399 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, May 17, 2022 at 09:52:36AM +0200, Oscar Salvador wrote: > On Mon, May 16, 2022 at 08:03:49PM +0800, Muchun Song wrote: > > On Mon, May 16, 2022 at 12:38:46PM +0200, Oscar Salvador wrote: > > > On Mon, May 16, 2022 at 06:22:08PM +0800, Muchun Song wrote: > > > > --- a/mm/sparse.c > > > > +++ b/mm/sparse.c > > > > @@ -913,6 +913,13 @@ int __meminit sparse_add_section(int nid, unsigned long start_pfn, > > > > ms = __nr_to_section(section_nr); > > > > set_section_nid(section_nr, nid); > > > > __section_mark_present(ms, section_nr); > > > > + /* > > > > + * Mark whole section as non-optimizable once there is a subsection > > > > + * whose vmemmap pages are allocated from alternative allocator. The > > > > + * early section is always optimizable. > > > > + */ > > > > + if (!early_section(ms) && altmap) > > > > + section_mark_cannot_optimize_vmemmap(ms); > > > > > > Because no one expects those sections to be removed? > > > IIRC, early_section + altmap only happened in case of sub-section pmem > > > scenario? > > > > Right. The commit ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") > > has more information. > > > > > I guess my question is: can we really have early_sections coming > > > from alternative allocator? > > > > > > > We can't. The early section does not consider partially being > > populated currently. > > Then, IIUC, we can forget about the early_section() check? > Sorry for the confusing. I mean early_section() should be checked. I could find a comment in section_activate, that says: /* * The early init code does not consider partially populated * initial sections, it simply assumes that memory will never be * referenced. If we hot-add memory into such a section then we * do not need to populate the memmap and can simply reuse what * is already there. */ if (nr_pages < PAGES_PER_SECTION && early_section(ms)) return pfn_to_page(pfn); We can see that we could hot-add a sub-section within a early section. So I think early_section + altmap could happened in this case, then we could not drop that check. Right? Thanks.