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 D8A51C433EF for ; Fri, 17 Jun 2022 09:10:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65C826B0071; Fri, 17 Jun 2022 05:10:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60BDC6B0073; Fri, 17 Jun 2022 05:10:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D3F16B0074; Fri, 17 Jun 2022 05:10:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3DCC46B0071 for ; Fri, 17 Jun 2022 05:10:31 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 104011649 for ; Fri, 17 Jun 2022 09:10:31 +0000 (UTC) X-FDA: 79587157062.07.0FE5698 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf18.hostedemail.com (Postfix) with ESMTP id 871131C0087 for ; Fri, 17 Jun 2022 09:10:27 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id d5so3361984plo.12 for ; Fri, 17 Jun 2022 02:10:27 -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=ErDfRcZhT9Lf0Mnh9cO6ygQL2ijrScLa0RIJt67Z2D4=; b=lQomTkBg+EqCThhBADFZyIqepjXyr4CWMefwfip0o7eYW7ggEW4QKQoiPoQ1pomoHD qrg3TOa8dtJdSptD05Ejla1fDaXO4bGZd/2nXiGc6Y0XNP/1Axq/kId0isLVfHXVxum5 6WPA54qNiK7rwDl+7CMZ+Jhoe0Iqq7MnpkO7oYqaROfq0BoC3vUSQxg/HqQFh0yYTeJj 4CcVRKUD62I8eCyKZv/kJkV/AzusXwjzi++8rIAjNlPz1rK0076THJuW/n8ZrMpSrJQl 5RPwKnL5WZ2PzuYxUnA78xT7pua+EU4AK7Bv/jlD6+hyqA0+TFZIBZBTdYGo6ExOKtXf NuWA== 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=ErDfRcZhT9Lf0Mnh9cO6ygQL2ijrScLa0RIJt67Z2D4=; b=c0hPGlBXaN0VsalMiCxNK3O6e/o/IkOl2RXphk4keb2CFyGfGlE2mD3yvNCdKy3zDt 268N2KezPZARE9u98HmDdQ4REFtk4nJ3gQisuFcd7uFhzx/6nq4dwuU5W52LsNXcRAsO hmh0AApkKYJR/iFI+lPVVw5QZZ/qxIo8sd3Y+v/eCmLSgdr/G/BwzyiLnedcB7XaatWK cLKybMa4Mu9U7O2V0L8Nzuw+RNcCPbuur1O3HR8NSioSdq50frb7YU7sL+PWqBXN3cn7 pMaCllqfRGDE+x4qp2lT7w2E7qkpqwcWQ90XkDM5gGbhGjzQuCMjMoIHhQDe7khPZfkA QsOQ== X-Gm-Message-State: AJIora/sSiRbKKV1m0LCJ3MEaWscDgG4ZKdQxupNPuKjDL6G2uuZAvjN bOuwoc6WQEhcOEgAhfKe9gfs2Q== X-Google-Smtp-Source: AGRyM1uXg0lH0GSFNVuOXTioY9vD8bTkRpVilNoA8/nb84rwN6eUxZIKTBYtgSfrbgWJxjoVRK/3xQ== X-Received: by 2002:a17:90a:c981:b0:1e6:75f0:d4ea with SMTP id w1-20020a17090ac98100b001e675f0d4eamr20607932pjt.37.1655457026198; Fri, 17 Jun 2022 02:10:26 -0700 (PDT) Received: from localhost ([139.177.225.255]) by smtp.gmail.com with ESMTPSA id l15-20020a17090a384f00b001e31f4cc977sm2815291pjf.56.2022.06.17.02.10.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jun 2022 02:10:25 -0700 (PDT) Date: Fri, 17 Jun 2022 17:10:23 +0800 From: Muchun Song To: David Hildenbrand Cc: Oscar Salvador , corbet@lwn.net, akpm@linux-foundation.org, paulmck@kernel.org, mike.kravetz@oracle.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, duanxiongchun@bytedance.com, smuchun@gmail.com Subject: Re: [PATCH v2 2/2] mm: memory_hotplug: introduce SECTION_CANNOT_OPTIMIZE_VMEMMAP Message-ID: References: <20220520025538.21144-1-songmuchun@bytedance.com> <20220520025538.21144-3-songmuchun@bytedance.com> <53024884-0182-df5f-9ca2-00652c64ce36@redhat.com> <24d5ec20-9c9e-93aa-11f4-c4619f51f7d1@redhat.com> <79a1ca29-de8e-6456-460b-a9099340fec4@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <79a1ca29-de8e-6456-460b-a9099340fec4@redhat.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655457028; a=rsa-sha256; cv=none; b=Lo9Kg3iisj1Cc76t/Ad0DCqR55KLiKSIB2g9X9iqb9fOGEvtE5S+/3eFimux/35v5YxgI/ rjJE4nKUNZ8G53Gx4j70nydv2XaviXtXsHKrF7PPux1dCo5Sc8lmnuKtcR/pdWlrGIihTL gFBQxpA6/yE0lWw/LDA9AJLvWUpn+xQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=lQomTkBg; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf18.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655457028; 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=ErDfRcZhT9Lf0Mnh9cO6ygQL2ijrScLa0RIJt67Z2D4=; b=04St7snxmcJVYc8f+6mXrHH278Z/zpcxL+Fo5LYHRjugxDCIeEB1fgW0bULuSAXxdagFkc 0oRsmgoDCXnH4dqX8A4iwwiGYfoDQbWxpTbyrWODnKEIETNHvhgJv9svc7ttZBQgt9Xed4 17WKT/Ee5asKZ6gtAxTQTfpQYPAsFx0= Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=lQomTkBg; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf18.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-Rspam-User: X-Stat-Signature: dmnr9a7tof84ghcrgkkdfqn6pqfdb9xh X-Rspamd-Queue-Id: 871131C0087 X-Rspamd-Server: rspam08 X-HE-Tag: 1655457027-983156 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 Fri, Jun 17, 2022 at 09:39:27AM +0200, David Hildenbrand wrote: > On 17.06.22 09:28, Muchun Song wrote: > > On Fri, Jun 17, 2022 at 07:46:53AM +0200, Oscar Salvador wrote: > >> On Thu, Jun 16, 2022 at 09:30:33AM +0200, David Hildenbrand wrote: > >>> IIRC, that was used to skip these patches on the offlining path before > >>> we provided the ranges to offline_pages(). > >> > >> Yeah, it was designed for that purpose back then. > >> > >>> I'd not mess with PG_reserved, and give them a clearer name, to not > >>> confuse them with other, ordinary, vmemmap pages that are not > >>> self-hosted (maybe in the future we might want to flag all vmemmap pages > >>> with a new type?). > >> > >> Not sure whether a new type is really needed, or to put it another way, I > >> cannot see the benefit. > >> > >>> > >>> I'd just try reusing the flag PG_owner_priv_1. And eventually, flag all > >>> (v)memmap pages with a type PG_memmap. However, the latter would be > >>> optional and might not be strictly required > >>> > >>> > >>> So what think could make sense is > >>> > >>> /* vmemmap pages that are self-hosted and cannot be optimized/freed. */ > >>> PG_vmemmap_self_hosted = PG_owner_priv_1, > >> > >> Sure, I just lightly tested the below, and seems to work, but not sure > >> whether that is what you are referring to. > >> @Munchun: thoughts? > >> > > > > I think it works and fits my requirement. > > > >> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > >> index e66f7aa3191d..a4556afd7bda 100644 > >> --- a/include/linux/page-flags.h > >> +++ b/include/linux/page-flags.h > >> @@ -193,6 +193,11 @@ enum pageflags { > >> > >> /* Only valid for buddy pages. Used to track pages that are reported */ > >> PG_reported = PG_uptodate, > >> + > >> +#ifdef CONFIG_MEMORY_HOTPLUG > >> + /* For self-hosted memmap pages */ > >> + PG_vmemmap_self_hosted = PG_owner_priv_1, > >> +#endif > >> }; > >> > >> #define PAGEFLAGS_MASK ((1UL << NR_PAGEFLAGS) - 1) > >> @@ -628,6 +633,10 @@ PAGEFLAG_FALSE(SkipKASanPoison, skip_kasan_poison) > >> */ > >> __PAGEFLAG(Reported, reported, PF_NO_COMPOUND) > >> > >> +#ifdef CONFIG_MEMORY_HOTPLUG > >> +PAGEFLAG(Vmemmap_self_hosted, vmemmap_self_hosted, PF_ANY) > >> +#endif > >> + > >> /* > >> * On an anonymous page mapped into a user virtual memory area, > >> * page->mapping points to its anon_vma, not to a struct address_space; > >> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c > >> index 1089ea8a9c98..e2de7ed27e9e 100644 > >> --- a/mm/hugetlb_vmemmap.c > >> +++ b/mm/hugetlb_vmemmap.c > >> @@ -101,6 +101,14 @@ void hugetlb_vmemmap_free(struct hstate *h, struct page *head) > >> { > >> unsigned long vmemmap_addr = (unsigned long)head; > >> unsigned long vmemmap_end, vmemmap_reuse, vmemmap_pages; > >> + struct mem_section *ms = __pfn_to_section(page_to_pfn(head)); > >> + struct page *memmap; > >> + > >> + memmap = sparse_decode_mem_map(ms->section_mem_map, > >> + pfn_to_section_nr(page_to_pfn(head))); > >> + > >> + if (PageVmemmap_self_hosted(memmap)) > >> + return; > > > > I think here needs a loop if it is a 1GB page (spans multiple sections). > > Right? Here is an implementation based on another approach. But I think > > your implementation is more simpler and efficient. Would you mind me > > squash your diff into my patch and with your "Co-developed-by"? > > Due to hugtlb alignment requirements, and the vmemmap pages being at the > start of the hotplugged memory region, I think that cannot currently > happen. Checking the first vmemmap page might be good enough for now, > and probably for the future. > If the memory block size is 128MB, then a 1GB huge page spans 8 blocks. Is it possible that some blocks of them are vmemmap-hosted? Thanks.