All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Wei Yang <richard.weiyang@gmail.com>,
	Matthew Wilcox <willy@infradead.org>, Baoquan He <bhe@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, david@redhat.com
Subject: Re: [PATCH v2] mm/sparse.c: Use kvmalloc_node/kvfree to alloc/free memmap for the classic sparse
Date: Fri, 13 Mar 2020 21:54:36 +0000	[thread overview]
Message-ID: <20200313215436.df7tqqhrywingujs@master> (raw)
In-Reply-To: <20200313145733.GE21007@dhcp22.suse.cz>

On Fri, Mar 13, 2020 at 03:57:33PM +0100, Michal Hocko wrote:
>On Thu 12-03-20 14:18:26, Wei Yang wrote:
>> On Thu, Mar 12, 2020 at 06:34:16AM -0700, Matthew Wilcox wrote:
>> >On Thu, Mar 12, 2020 at 09:08:22PM +0800, Baoquan He wrote:
>> >> This change makes populate_section_memmap()/depopulate_section_memmap
>> >> much simpler.
>> >> 
>> >> Suggested-by: Michal Hocko <mhocko@kernel.org>
>> >> Signed-off-by: Baoquan He <bhe@redhat.com>
>> >> ---
>> >> v1->v2:
>> >>   The old version only used __get_free_pages() to replace alloc_pages()
>> >>   in populate_section_memmap().
>> >>   http://lkml.kernel.org/r/20200307084229.28251-8-bhe@redhat.com
>> >> 
>> >>  mm/sparse.c | 27 +++------------------------
>> >>  1 file changed, 3 insertions(+), 24 deletions(-)
>> >> 
>> >> diff --git a/mm/sparse.c b/mm/sparse.c
>> >> index bf6c00a28045..362018e82e22 100644
>> >> --- a/mm/sparse.c
>> >> +++ b/mm/sparse.c
>> >> @@ -734,35 +734,14 @@ static void free_map_bootmem(struct page *memmap)
>> >>  struct page * __meminit populate_section_memmap(unsigned long pfn,
>> >>  		unsigned long nr_pages, int nid, struct vmem_altmap *altmap)
>> >>  {
>> >> -	struct page *page, *ret;
>> >> -	unsigned long memmap_size = sizeof(struct page) * PAGES_PER_SECTION;
>> >> -
>> >> -	page = alloc_pages(GFP_KERNEL|__GFP_NOWARN, get_order(memmap_size));
>> >> -	if (page)
>> >> -		goto got_map_page;
>> >> -
>> >> -	ret = vmalloc(memmap_size);
>> >> -	if (ret)
>> >> -		goto got_map_ptr;
>> >> -
>> >> -	return NULL;
>> >> -got_map_page:
>> >> -	ret = (struct page *)pfn_to_kaddr(page_to_pfn(page));
>> >> -got_map_ptr:
>> >> -
>> >> -	return ret;
>> >> +	return kvmalloc_node(sizeof(struct page) * PAGES_PER_SECTION,
>> >> +			     GFP_KERNEL|__GFP_NOWARN, nid);
>> >
>> >Use of NOWARN here is inappropriate, because there's no fallback.
>> 
>> Hmm... this replacement is a little tricky.
>> 
>> When you look into kvmalloc_node(), it will do the fallback if the size is
>> bigger than PAGE_SIZE. This means the change here may not be equivalent as
>> before if memmap_size is less than PAGE_SIZE.
>
>I do not understand your concern to be honest. Even if a sub page memmap
>size was possible (I haven't checked), I fail to see why kmalloc would
>fail to allocate while vmalloc would have a bigger chance to succeed.
>

You are right. My concern is just at kvmalloc_node() level.

After I look deep into the implementation, __vmalloc_area_node(), it will
still allocate memory on PAGE_SIZE base and fill up kernel page table.

That's why kvmalloc_node() stops trying when size is less than PAGE_SIZE.

Learned one more point. Thanks

>-- 
>Michal Hocko
>SUSE Labs

-- 
Wei Yang
Help you, Help me

  reply	other threads:[~2020-03-13 21:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-12 13:08 [PATCH v2] mm/sparse.c: Use kvmalloc_node/kvfree to alloc/free memmap for the classic sparse Baoquan He
2020-03-12 13:34 ` Matthew Wilcox
2020-03-12 13:54   ` Baoquan He
2020-03-12 14:18   ` Wei Yang
2020-03-12 14:25     ` Matthew Wilcox
2020-03-12 22:50       ` Wei Yang
2020-03-13  0:00         ` Matthew Wilcox
2020-03-13 14:35           ` David Hildenbrand
2020-03-13 14:46           ` Vlastimil Babka
2020-03-13 14:57     ` Michal Hocko
2020-03-13 21:54       ` Wei Yang [this message]
2020-03-12 14:17 ` [PATCH v3] " Baoquan He
2020-03-13 14:56   ` Michal Hocko
2020-03-14  0:53     ` Baoquan He
2020-03-14 12:56       ` Michal Hocko
2020-03-15 13:01         ` Baoquan He
2020-03-14  1:12     ` Baoquan He
2020-03-13 15:04   ` David Hildenbrand
2020-03-16  7:14     ` Baoquan He

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=20200313215436.df7tqqhrywingujs@master \
    --to=richard.weiyang@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=willy@infradead.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.