From: Pavel Tatashin <pasha.tatashin@oracle.com>
To: osalvador@techadventures.net
Cc: Steven Sistare <steven.sistare@oracle.com>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
kirill.shutemov@linux.intel.com, Michal Hocko <mhocko@suse.com>,
Linux Memory Management List <linux-mm@kvack.org>,
dan.j.williams@intel.com, jack@suse.cz, jglisse@redhat.com,
Souptick Joarder <jrdr.linux@gmail.com>,
bhe@redhat.com, gregkh@linuxfoundation.org,
Vlastimil Babka <vbabka@suse.cz>,
Wei Yang <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 07:10:42 -0400 [thread overview]
Message-ID: <CAGM2reavPdp48_=cw1g3Jmz2+ZLU9DkOQbdwAu17v39OCkjVPg@mail.gmail.com> (raw)
In-Reply-To: <20180713095934.GB15039@techadventures.net>
> 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.
Hi Oscar,
Right, I also like that this solution removes one extra loop, thus
reduces the code size. We were populating pages in one place, and then
loop again to set sections, now we do both in one place, but still
allow preallocation of memory to reduces fragmentation on all
platforms. However, I still wanted to see if someone could test on
real hardware.
Thank you,
Pavel
next prev parent reply other threads:[~2018-07-13 11:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-12 20:37 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 11:15 ` Pavel Tatashin
2018-07-13 9:59 ` [PATCH v5 0/5] sparse_init rewrite Oscar Salvador
2018-07-13 11:10 ` Pavel Tatashin [this message]
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='CAGM2reavPdp48_=cw1g3Jmz2+ZLU9DkOQbdwAu17v39OCkjVPg@mail.gmail.com' \
--to=pasha.tatashin@oracle.com \
--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=osalvador@techadventures.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox