All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <songmuchun@bytedance.com>
To: Oscar Salvador <osalvador@suse.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com,
	dave.hansen@linux.intel.com, luto@kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	viro@zeniv.linux.org.uk,
	Andrew Morton <akpm@linux-foundation.org>,
	paulmck@kernel.org, mchehab+huawei@kernel.org,
	pawan.kumar.gupta@linux.intel.com,
	Randy Dunlap <rdunlap@infradead.org>,
	oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de,
	Mina Almasry <almasrymina@google.com>,
	David Rientjes <rientjes@google.com>,
	Matthew Wilcox <willy@infradead.org>,
	Michal Hocko <mhocko@suse.com>,
	"Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>,
	David Hildenbrand <david@redhat.com>,
	Xiongchun duan <duanxiongchun@bytedance.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Linux Memory Management List <linux-mm@kvack.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [External] Re: [PATCH v8 03/12] mm/bootmem_info: Introduce free_bootmem_page helper
Date: Thu, 10 Dec 2020 23:22:15 +0800	[thread overview]
Message-ID: <CAMZfGtW6yJPR2yUR0h11=QxY8G6V8oZAnArYh4SQPn370cBLpQ@mail.gmail.com> (raw)
In-Reply-To: <20201210141547.GA8538@localhost.localdomain>

On Thu, Dec 10, 2020 at 10:16 PM Oscar Salvador <osalvador@suse.de> wrote:
>
> On Thu, Dec 10, 2020 at 11:55:17AM +0800, Muchun Song wrote:
> > Any memory allocated via the memblock allocator and not via the buddy
> > will be makred reserved already in the memmap. For those pages, we can
>          marked

Thanks.

> > call free_bootmem_page() to free it to buddy allocator.
> >
> > Becasue we wan to free some vmemmap pages of the HugeTLB to the buddy
> Because     want
> > allocator, we can use this helper to do that in the later patchs.
>                                                            patches
>

Thanks.

> To be honest, I think if would be best to introduce this along with
> patch#4, so we get to see where it gets used.
>
> > Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> > ---
> >  include/linux/bootmem_info.h | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/include/linux/bootmem_info.h b/include/linux/bootmem_info.h
> > index 4ed6dee1adc9..20a8b0df0c39 100644
> > --- a/include/linux/bootmem_info.h
> > +++ b/include/linux/bootmem_info.h
> > @@ -3,6 +3,7 @@
> >  #define __LINUX_BOOTMEM_INFO_H
> >
> >  #include <linux/mmzone.h>
> > +#include <linux/mm.h>
>
> <linux/mm.h> already includes <linux/mmzone.h>

Yeah. Can remove this.

>
> > +static inline void free_bootmem_page(struct page *page)
> > +{
> > +     unsigned long magic = (unsigned long)page->freelist;
> > +
> > +     /* bootmem page has reserved flag in the reserve_bootmem_region */
> reserve_bootmem_region sets the reserved flag on bootmem pages?

Right.

>
> > +     VM_WARN_ON(!PageReserved(page) || page_ref_count(page) != 2);
>
> We do check for PageReserved in patch#4 before calling in here.
> Do we need yet another check here? IOW, do we need to be this paranoid?

Yeah, do not need to check again. We can remove it.

>
> > +     if (magic == SECTION_INFO || magic == MIX_SECTION_INFO)
> > +             put_page_bootmem(page);
> > +     else
> > +             WARN_ON(1);
>
> Lately, some people have been complaining about using WARN_ON as some
> systems come with panic_on_warn set.
>
> I would say that in this case it does not matter much as if the vmemmap
> pages are not either SECTION_INFO or MIX_SECTION_INFO it means that a
> larger corruption happened elsewhere.
>
> But I think I would align the checks here.
> It does not make sense to me to only scream under DEBUG_VM if page's
> refcount differs from 2, and have a WARN_ON if the page we are trying
> to free was not used for the memmap array.
> Both things imply a corruption, so I would set the checks under the same
> configurations.

Do you suggest changing them all to VM_DEBUG_ON?

>
> --
> Oscar Salvador
> SUSE L3



-- 
Yours,
Muchun

  reply	other threads:[~2020-12-10 15:24 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-10  3:55 [PATCH v8 00/12] Free some vmemmap pages of HugeTLB page Muchun Song
2020-12-10  3:55 ` [PATCH v8 01/12] mm/memory_hotplug: Factor out bootmem core functions to bootmem_info.c Muchun Song
2020-12-10  3:55 ` [PATCH v8 02/12] mm/hugetlb: Introduce a new config HUGETLB_PAGE_FREE_VMEMMAP Muchun Song
2020-12-10  3:55 ` [PATCH v8 03/12] mm/bootmem_info: Introduce free_bootmem_page helper Muchun Song
2020-12-10 14:15   ` Oscar Salvador
2020-12-10 15:22     ` Muchun Song [this message]
2020-12-10 15:22       ` [External] " Muchun Song
2020-12-10 15:26       ` Muchun Song
2020-12-10 15:26         ` Muchun Song
2020-12-10  3:55 ` [PATCH v8 04/12] mm/hugetlb: Free the vmemmap pages associated with each HugeTLB page Muchun Song
2020-12-10 14:42   ` Oscar Salvador
2020-12-10 14:44     ` Oscar Salvador
2020-12-10 15:58       ` [External] " Muchun Song
2020-12-10 15:58         ` Muchun Song
2020-12-10 15:57     ` Muchun Song
2020-12-10 15:57       ` Muchun Song
2020-12-10  3:55 ` [PATCH v8 05/12] mm/hugetlb: Defer freeing of HugeTLB pages Muchun Song
2020-12-10  3:55 ` [PATCH v8 06/12] mm/hugetlb: Allocate the vmemmap pages associated with each HugeTLB page Muchun Song
2020-12-11  9:35   ` Oscar Salvador
2020-12-11 10:52     ` David Hildenbrand
2020-12-11 13:01     ` [External] " Muchun Song
2020-12-11 13:01       ` Muchun Song
2020-12-10  3:55 ` [PATCH v8 07/12] mm/hugetlb: Set the PageHWPoison to the raw error page Muchun Song
2020-12-10 11:11   ` Muchun Song
2020-12-10 11:11     ` Muchun Song
2020-12-11 13:36   ` Oscar Salvador
2020-12-11 14:08     ` [External] " Muchun Song
2020-12-11 14:08       ` Muchun Song
2020-12-10  3:55 ` [PATCH v8 08/12] mm/hugetlb: Flush work when dissolving hugetlb page Muchun Song
2020-12-10  3:55 ` [PATCH v8 09/12] mm/hugetlb: Add a kernel parameter hugetlb_free_vmemmap Muchun Song
2020-12-10 10:04   ` Oscar Salvador
2020-12-10 12:26     ` [External] " Muchun Song
2020-12-10 12:26       ` Muchun Song
2020-12-10  3:55 ` [PATCH v8 10/12] mm/hugetlb: Introduce nr_free_vmemmap_pages in the struct hstate Muchun Song
2020-12-10 10:15   ` Oscar Salvador
2020-12-10 12:32     ` [External] " Muchun Song
2020-12-10 12:32       ` Muchun Song
2020-12-10  3:55 ` [PATCH v8 11/12] mm/hugetlb: Gather discrete indexes of tail page Muchun Song
2020-12-10  3:55 ` [PATCH v8 12/12] mm/hugetlb: Optimize the code with the help of the compiler Muchun Song
2020-12-10 10:25   ` Oscar Salvador
2020-12-10 12:14     ` [External] " Muchun Song
2020-12-10 12:14       ` Muchun Song
2020-12-10 13:16       ` Oscar Salvador
2020-12-10 13:29         ` Muchun Song
2020-12-10 13:29           ` Muchun Song
2020-12-10 16:19           ` Muchun Song
2020-12-10 16:19             ` Muchun Song
2020-12-10  9:18 ` [PATCH v8 00/12] Free some vmemmap pages of HugeTLB page Oscar Salvador

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMZfGtW6yJPR2yUR0h11=QxY8G6V8oZAnArYh4SQPn370cBLpQ@mail.gmail.com' \
    --to=songmuchun@bytedance.com \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=anshuman.khandual@arm.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=duanxiongchun@bytedance.com \
    --cc=hpa@zytor.com \
    --cc=jroedel@suse.de \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=mingo@redhat.com \
    --cc=oneukum@suse.com \
    --cc=osalvador@suse.de \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=song.bao.hua@hisilicon.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.