linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Pasha Tatashin <pasha.tatashin@oracle.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, borntraeger@de.ibm.com,
	heiko.carstens@de.ibm.com, davem@davemloft.net
Subject: Re: [v3 0/9] parallelized "struct page" zeroing
Date: Fri, 26 May 2017 12:45:55 -0400	[thread overview]
Message-ID: <07a6772b-711d-4fdc-f688-db76f1ec4c45@oracle.com> (raw)
In-Reply-To: <20170516083601.GB2481@dhcp22.suse.cz>

Hi Michal,

I have considered your proposals:

1. Making memset(0) unconditional inside __init_single_page() is not 
going to work because it slows down SPARC, and ppc64. On SPARC even the 
BSTI optimization that I have proposed earlier won't work, because after 
consulting with other engineers I was told that stores (without loads!) 
after BSTI without membar are unsafe

2. Adding ARCH_WANT_LARGE_PAGEBLOCK_INIT is not going to solve the 
problem, because while arch might want a large memset(), it still wants 
to get the benefit of parallelized struct page initialization.

3. Another approach that have I considered is moving memset() above 
__init_single_page() and do it in a larger chunks. However, this 
solution is also not going to work, because inside the loops, there are 
cases where "struct page"s are skipped, so every single page is checked:
early_pfn_valid(pfn), early_pfn_in_nid(), and also mirroed_kernelcore cases.

> I wouldn't be so sure about this. If any other platform has a similar
> issues with small memset as sparc then the overhead is just papered over
> by parallel initialization.

That is true, and that is fine, because parallelization gives an order 
of magnitude better improvements compared to trade of slower single 
thread performance. Remember, this will happen during boot and memory 
hotplug only, and not something that will eat up computing resources 
during runtime.

So, at the moment I cannot really find a better solution compared to 
what I have proposed: do memset() inside __init_single_page() only when 
deferred initialization is enabled.

Pasha

  reply	other threads:[~2017-05-26 16:46 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 17:03 [v3 0/9] parallelized "struct page" zeroing Pavel Tatashin
2017-05-05 17:03 ` [v3 1/9] sparc64: simplify vmemmap_populate Pavel Tatashin
2017-05-05 17:03 ` [v3 2/9] mm: defining memblock_virt_alloc_try_nid_raw Pavel Tatashin
2017-05-05 17:03 ` [v3 3/9] mm: add "zero" argument to vmemmap allocators Pavel Tatashin
2017-05-13 19:17   ` kbuild test robot
2017-05-05 17:03 ` [v3 4/9] mm: do not zero vmemmap_buf Pavel Tatashin
2017-05-05 17:03 ` [v3 5/9] mm: zero struct pages during initialization Pavel Tatashin
2017-05-05 17:03 ` [v3 6/9] sparc64: teach sparc not to zero struct pages memory Pavel Tatashin
2017-05-05 17:03 ` [v3 7/9] x86: teach x86 " Pavel Tatashin
2017-05-05 17:03 ` [v3 8/9] powerpc: teach platforms " Pavel Tatashin
2017-05-05 17:03 ` [v3 9/9] s390: " Pavel Tatashin
2017-05-08 11:36   ` Heiko Carstens
2017-05-15 18:24     ` Pasha Tatashin
2017-05-15 23:17       ` Heiko Carstens
2017-05-16  0:33         ` Pasha Tatashin
2017-05-09 18:12 ` [v3 0/9] parallelized "struct page" zeroing Michal Hocko
2017-05-09 18:54   ` Pasha Tatashin
2017-05-10  7:24     ` Michal Hocko
2017-05-10 13:42       ` Pasha Tatashin
2017-05-10 14:57         ` Michal Hocko
2017-05-10 15:01           ` Pasha Tatashin
2017-05-10 15:20             ` David Miller
2017-05-11 20:47             ` Pasha Tatashin
2017-05-11 20:59               ` Pasha Tatashin
2017-05-12 16:57                 ` David Miller
2017-05-12 17:24                   ` Pasha Tatashin
2017-05-12 17:37                     ` David Miller
2017-05-16 23:50                       ` Benjamin Herrenschmidt
2017-05-12 16:56               ` David Miller
2017-05-10 15:19           ` David Miller
2017-05-10 17:17             ` Matthew Wilcox
2017-05-10 18:00               ` David Miller
2017-05-10 21:11                 ` Matthew Wilcox
2017-05-11  8:05             ` Michal Hocko
2017-05-11 14:35               ` David Miller
2017-05-15 18:12   ` Pasha Tatashin
2017-05-15 19:38     ` Michal Hocko
2017-05-15 20:44       ` Pasha Tatashin
2017-05-16  8:36         ` Michal Hocko
2017-05-26 16:45           ` Pasha Tatashin [this message]
2017-05-29 11:53             ` Michal Hocko
2017-05-30 17:16               ` Pasha Tatashin
2017-05-31 16:31                 ` Michal Hocko
2017-05-31 16:51                   ` David Miller
2017-06-01  3:35                   ` Pasha Tatashin
2017-06-01  8:46                     ` Michal Hocko

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=07a6772b-711d-4fdc-f688-db76f1ec4c45@oracle.com \
    --to=pasha.tatashin@oracle.com \
    --cc=borntraeger@de.ibm.com \
    --cc=davem@davemloft.net \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mhocko@kernel.org \
    --cc=sparclinux@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).