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=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 BB176C55178 for ; Sun, 25 Oct 2020 15:43:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 000322080A for ; Sun, 25 Oct 2020 15:43:03 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ATpSfOCd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 000322080A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 24D1E6B005D; Sun, 25 Oct 2020 11:43:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FDA16B0062; Sun, 25 Oct 2020 11:43:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C4B76B0068; Sun, 25 Oct 2020 11:43:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0001.hostedemail.com [216.40.44.1]) by kanga.kvack.org (Postfix) with ESMTP id CB4376B005D for ; Sun, 25 Oct 2020 11:43: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 5F1FF181AC9CB for ; Sun, 25 Oct 2020 15:43:02 +0000 (UTC) X-FDA: 77410866204.17.feet68_040390b2726c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 3F170180D0180 for ; Sun, 25 Oct 2020 15:43:02 +0000 (UTC) X-HE-Tag: feet68_040390b2726c X-Filterd-Recvd-Size: 5311 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf48.hostedemail.com (Postfix) with ESMTP for ; Sun, 25 Oct 2020 15:43:01 +0000 (UTC) Received: from kernel.org (unknown [87.70.96.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 2DD4A2080A; Sun, 25 Oct 2020 15:42:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603640580; bh=N9t4JcJRF9OlaznQ2CFo7tNstRd5AmQcgZvZA/hb9NE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ATpSfOCdRRUdJQptjMZHclSfdxad8SDeNY3zHu3y587NyCGZewV+oW2Jq/G7h43fl njWo4IwZxGaYXtNI7OHQr3hg41mJAdPRrr5sJVyCXHKNhVcDD8OfgjTVPb6cSB0fSF KyBsBEF5Dr1uJGRxAkIt9ppFFPrRkvkhL7mqv4Gw= Date: Sun, 25 Oct 2020 17:42:53 +0200 From: Mike Rapoport To: Zhenhua Huang Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: fix page_owner initializing issue for arm32 Message-ID: <20201025154253.GH392079@kernel.org> References: <1602839640-13125-1-git-send-email-zhenhuah@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1602839640-13125-1-git-send-email-zhenhuah@codeaurora.org> 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, Oct 16, 2020 at 05:14:00PM +0800, Zhenhua Huang wrote: > Page owner of pages used by page owner itself used is missing on arm32 targets. > The reason is dummy_handle and failure_handle is not initialized correctly. > Buddy allocator is used to initialize these two handles. However, buddy > allocator is not ready when page owner calls it. This change fixed that by > initializing page owner after buddy initialization. > > The working flow before and after this change are: > original logic: > 1. allocated memory for page_ext(using memblock). Is anything that requires a memblock allocation FLATMEM? Any fundamental reason why wouldn't alloc_pages_exact_nid/vzalloc_node() work in this case? It seems to me that for FLATMEM configuration we can allocate the page_ext using alloc_pages() with a fallback to vzalloc_node() and then we can unify lot's of page_ext code and entirely drop page_ext_init_flatmem(). > 2. invoke the init callback of page_ext_ops like > page_owner(using buddy allocator). > 3. initialize buddy. > > after this change: > 1. allocated memory for page_ext(using memblock). > 2. initialize buddy. > 3. invoke the init callback of page_ext_ops like > page_owner(using buddy allocator). > > with the change, failure/dummy_handle can get its correct value and > page owner output for example has the one for page owner itself: > Page allocated via order 2, mask 0x6202c0(GFP_USER|__GFP_NOWARN), pid 1006, ts > 67278156558 ns > PFN 543776 type Unmovable Block 531 type Unmovable Flags 0x0() > init_page_owner+0x28/0x2f8 > invoke_init_callbacks_flatmem+0x24/0x34 > start_kernel+0x33c/0x5d8 > (null) > > Signed-off-by: Zhenhua Huang > --- > include/linux/page_ext.h | 8 ++++++++ > init/main.c | 2 ++ > mm/page_ext.c | 8 +++++++- > 3 files changed, 17 insertions(+), 1 deletion(-) > > diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h > index cfce186..aff81ba 100644 > --- a/include/linux/page_ext.h > +++ b/include/linux/page_ext.h > @@ -44,8 +44,12 @@ static inline void page_ext_init_flatmem(void) > { > } > extern void page_ext_init(void); > +static inline void page_ext_init_flatmem_late(void) > +{ > +} > #else > extern void page_ext_init_flatmem(void); > +extern void page_ext_init_flatmem_late(void); > static inline void page_ext_init(void) > { > } > @@ -76,6 +80,10 @@ static inline void page_ext_init(void) > { > } > > +static inline void page_ext_init_flatmem_late(void) > +{ > +} > + > static inline void page_ext_init_flatmem(void) > { > } > diff --git a/init/main.c b/init/main.c > index 130376e..b34c475 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -818,6 +818,8 @@ static void __init mm_init(void) > init_debug_pagealloc(); > report_meminit(); > mem_init(); > + /* page_owner must be initialized after buddy is ready */ > + page_ext_init_flatmem_late(); > kmem_cache_init(); > kmemleak_init(); > pgtable_init(); > diff --git a/mm/page_ext.c b/mm/page_ext.c > index a3616f7..373f7a1 100644 > --- a/mm/page_ext.c > +++ b/mm/page_ext.c > @@ -99,6 +99,13 @@ static void __init invoke_init_callbacks(void) > } > } > > +#if !defined(CONFIG_SPARSEMEM) > +void __init page_ext_init_flatmem_late(void) > +{ > + invoke_init_callbacks(); > +} > +#endif > + > static inline struct page_ext *get_entry(void *base, unsigned long index) > { > return base + page_ext_size * index; > @@ -177,7 +184,6 @@ void __init page_ext_init_flatmem(void) > goto fail; > } > pr_info("allocated %ld bytes of page_ext\n", total_usage); > - invoke_init_callbacks(); > return; > > fail: > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project > > -- Sincerely yours, Mike.