From: Oscar Salvador <osalvador@techadventures.net>
To: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
kirill.shutemov@linux.intel.com, mhocko@suse.com,
linux-mm@kvack.org, dan.j.williams@intel.com, jack@suse.cz,
jglisse@redhat.com, jrdr.linux@gmail.com, bhe@redhat.com,
gregkh@linuxfoundation.org, vbabka@suse.cz,
richard.weiyang@gmail.com, dave.hansen@intel.com,
rientjes@google.com, mingo@kernel.org,
abdhalee@linux.vnet.ibm.com, mpe@ellerman.id.au
Subject: Re: [PATCH v5 0/5] sparse_init rewrite
Date: Fri, 13 Jul 2018 11:59:34 +0200 [thread overview]
Message-ID: <20180713095934.GB15039@techadventures.net> (raw)
In-Reply-To: <20180712203730.8703-1-pasha.tatashin@oracle.com>
On Thu, Jul 12, 2018 at 04:37:25PM -0400, Pavel Tatashin wrote:
> Changelog:
> v5 - v4
> - Fixed the issue that was reported on ppc64 when
> CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER is removed
> - Consolidated the new buffer allocation between vmemmap
> and non-vmemmap variants of sparse layout.
> - Removed all review-by comments, because I had to do
> significant amount of changes compared to previous version
> and need another round of review.
> - I also would appreciate if those who reported problems with
> PPC64 could test this change.
About PPC64, your patchset fixes the issue as the population gets followed by a
sparse_init_one_section().
It can be seen here:
Before:
kernel: vmemmap_populate f000000000000000..f000000000004000, node 0
kernel: * f000000000000000..f000000000010000 allocated at (____ptrval____)
kernel: vmemmap_populate f000000000000000..f000000000008000, node 0
kernel: * f000000000000000..f000000000010000 allocated at (____ptrval____)
kernel: vmemmap_populate f000000000000000..f00000000000c000, node 0
kernel: * f000000000000000..f000000000010000 allocated at (____ptrval____)
After:
kernel: vmemmap_populate f000000000000000..f000000000004000, node 0
kernel: * f000000000000000..f000000000010000 allocated at (____ptrval____)
kernel: vmemmap_populate f000000000000000..f000000000008000, node 0
kernel: vmemmap_populate f000000000000000..f00000000000c000, node 0
kernel: vmemmap_populate f000000000000000..f000000000010000, node 0
kernel: vmemmap_populate f000000000010000..f000000000014000, node 0
kernel: * f000000000010000..f000000000020000 allocated at (____ptrval____)
As can be seen, before the patchset, we keep calling vmemmap_create_mapping() even if we
populated that section already, because of vmemmap_populated() checking for SECTION_HAS_MEM_MAP.
After the patchset, since each population is being followed by a call to sparse_init_one_section(),
when vmemmap_populated() gets called, we have SECTION_HAS_MEM_MAP already in case the section
was populated.
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2018-07-13 9:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-12 20:37 [PATCH v5 0/5] sparse_init rewrite Pavel Tatashin
2018-07-12 20:37 ` [PATCH v5 1/5] mm/sparse: abstract sparse buffer allocations Pavel Tatashin
2018-07-12 22:45 ` Andrew Morton
2018-07-13 13:17 ` Oscar Salvador
2018-07-13 13:24 ` Pavel Tatashin
2018-07-13 20:02 ` Andrew Morton
2018-07-12 20:37 ` [PATCH v5 2/5] mm/sparse: use the new sparse buffer functions in non-vmemmap Pavel Tatashin
2018-07-12 20:37 ` [PATCH v5 3/5] mm/sparse: move buffer init/fini to the common place Pavel Tatashin
2018-07-12 20:37 ` [PATCH v5 4/5] mm/sparse: add new sparse_init_nid() and sparse_init() Pavel Tatashin
2018-07-13 12:03 ` Oscar Salvador
2018-07-13 12:37 ` Pavel Tatashin
2018-07-12 20:37 ` [PATCH v5 5/5] mm/sparse: delete old sprase_init and enable new one Pavel Tatashin
2018-07-13 9:09 ` Oscar Salvador
2018-07-13 9:09 ` Oscar Salvador
2018-07-13 11:15 ` Pavel Tatashin
2018-07-13 9:59 ` Oscar Salvador [this message]
2018-07-13 11:10 ` [PATCH v5 0/5] sparse_init rewrite Pavel Tatashin
2018-07-16 6:40 ` Michael Ellerman
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=20180713095934.GB15039@techadventures.net \
--to=osalvador@techadventures.net \
--cc=abdhalee@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=daniel.m.jordan@oracle.com \
--cc=dave.hansen@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jack@suse.cz \
--cc=jglisse@redhat.com \
--cc=jrdr.linux@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=pasha.tatashin@oracle.com \
--cc=richard.weiyang@gmail.com \
--cc=rientjes@google.com \
--cc=steven.sistare@oracle.com \
--cc=vbabka@suse.cz \
/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.