From: Baoquan He <bhe@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
akpm@linux-foundation.org, rppt@linux.ibm.com, osalvador@suse.de,
willy@infradead.org, william.kucharski@oracle.com
Subject: Re: [PATCH v2 2/4] mm/sparse: Optimize sparse_add_one_section()
Date: Tue, 26 Mar 2019 21:45:22 +0800 [thread overview]
Message-ID: <20190326134522.GB21943@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20190326101710.GN28406@dhcp22.suse.cz>
On 03/26/19 at 11:17am, Michal Hocko wrote:
> On Tue 26-03-19 18:08:17, Baoquan He wrote:
> > On 03/26/19 at 10:29am, Michal Hocko wrote:
> > > On Tue 26-03-19 17:02:25, Baoquan He wrote:
> > > > Reorder the allocation of usemap and memmap since usemap allocation
> > > > is much simpler and easier. Otherwise hard work is done to make
> > > > memmap ready, then have to rollback just because of usemap allocation
> > > > failure.
> > >
> > > Is this really worth it? I can see that !VMEMMAP is doing memmap size
> > > allocation which would be 2MB aka costly allocation but we do not do
> > > __GFP_RETRY_MAYFAIL so the allocator backs off early.
> >
> > In !VMEMMAP case, it truly does simple allocation directly. surely
> > usemap which size is 32 is smaller. So it doesn't matter that much who's
> > ahead or who's behind. However, this benefit a little in VMEMMAP case.
>
> How does it help there? The failure should be even much less probable
> there because we simply fall back to a small 4kB pages and those
> essentially never fail.
OK, I am fine to drop it. Or only put the section existence checking
earlier to avoid unnecessary usemap/memmap allocation?
From 7594b86ebf5d6fcc8146eca8fc5625f1961a15b1 Mon Sep 17 00:00:00 2001
From: Baoquan He <bhe@redhat.com>
Date: Tue, 26 Mar 2019 18:48:39 +0800
Subject: [PATCH] mm/sparse: Check section's existence earlier in
sparse_add_one_section()
No need to allocate usemap and memmap if section has been present.
And can clean up the handling on failure.
Signed-off-by: Baoquan He <bhe@redhat.com>
---
mm/sparse.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 363f9d31b511..f564b531e0f7 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -714,7 +714,13 @@ int __meminit sparse_add_one_section(int nid, unsigned long start_pfn,
ret = sparse_index_init(section_nr, nid);
if (ret < 0 && ret != -EEXIST)
return ret;
- ret = 0;
+
+ ms = __pfn_to_section(start_pfn);
+ if (ms->section_mem_map & SECTION_MARKED_PRESENT) {
+ ret = -EEXIST;
+ goto out;
+ }
+
memmap = kmalloc_section_memmap(section_nr, nid, altmap);
if (!memmap)
return -ENOMEM;
@@ -724,12 +730,6 @@ int __meminit sparse_add_one_section(int nid, unsigned long start_pfn,
return -ENOMEM;
}
- ms = __pfn_to_section(start_pfn);
- if (ms->section_mem_map & SECTION_MARKED_PRESENT) {
- ret = -EEXIST;
- goto out;
- }
-
/*
* Poison uninitialized struct pages in order to catch invalid flags
* combinations.
@@ -739,12 +739,7 @@ int __meminit sparse_add_one_section(int nid, unsigned long start_pfn,
section_mark_present(ms);
sparse_init_one_section(ms, section_nr, memmap, usemap);
-out:
- if (ret < 0) {
- kfree(usemap);
- __kfree_section_memmap(memmap, altmap);
- }
- return ret;
+ return 0;
}
#ifdef CONFIG_MEMORY_HOTREMOVE
--
2.17.2
next prev parent reply other threads:[~2019-03-26 13:45 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 9:02 [PATCH v2 0/4] Clean up comments and codes in sparse_add_one_section() Baoquan He
2019-03-26 9:02 ` [PATCH v2 1/4] mm/sparse: Clean up the obsolete code comment Baoquan He
2019-03-26 9:23 ` Mike Rapoport
2019-03-26 9:23 ` Michal Hocko
2019-03-26 9:30 ` Baoquan He
2019-03-26 9:36 ` Chao Fan
2019-03-26 9:43 ` Baoquan He
2019-03-26 9:46 ` Chao Fan
2019-03-26 9:02 ` [PATCH v2 2/4] mm/sparse: Optimize sparse_add_one_section() Baoquan He
2019-03-26 9:23 ` Mike Rapoport
2019-03-26 9:29 ` Michal Hocko
2019-03-26 10:08 ` Baoquan He
2019-03-26 10:17 ` Michal Hocko
2019-03-26 13:45 ` Baoquan He [this message]
2019-03-26 13:57 ` Mike Rapoport
2019-03-26 14:03 ` Michal Hocko
2019-03-26 14:18 ` Baoquan He
2019-03-26 14:31 ` Michal Hocko
2019-03-26 22:57 ` Baoquan He
2019-03-26 9:02 ` [PATCH v2 3/4] mm/sparse: Rename function related to section memmap allocation/free Baoquan He
2019-03-26 9:02 ` [PATCH v2 4/4] drivers/base/memory.c: Rename the misleading parameter Baoquan He
2019-03-26 9:20 ` Rafael J. Wysocki
2019-03-26 9:33 ` Michal Hocko
2019-03-26 11:43 ` Matthew Wilcox
2019-03-26 12:42 ` Baoquan He
2019-03-29 6:44 ` [PATCH v2 0/4] Clean up comments and codes in sparse_add_one_section() 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=20190326134522.GB21943@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=osalvador@suse.de \
--cc=rppt@linux.ibm.com \
--cc=william.kucharski@oracle.com \
--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.