From: Pasha Tatashin <pasha.tatashin@oracle.com>
To: David Miller <davem@davemloft.net>
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, willy@infradead.org
Subject: Re: [v2 3/5] mm: add "zero" argument to vmemmap allocators
Date: Wed, 3 May 2017 11:05:45 -0400 [thread overview]
Message-ID: <3921e0c8-2c18-60e9-cc99-78dbed2dce90@oracle.com> (raw)
In-Reply-To: <20170503.103428.1598887340082574002.davem@davemloft.net>
Hi Dave,
Thank you for the review. I will address your comment and update patchset..
Pasha
On 05/03/2017 10:34 AM, David Miller wrote:
> From: Pavel Tatashin <pasha.tatashin@oracle.com>
> Date: Fri, 24 Mar 2017 15:19:50 -0400
>
>> Allow clients to request non-zeroed memory from vmemmap allocator.
>> The following two public function have a new boolean argument called zero:
>>
>> __vmemmap_alloc_block_buf()
>> vmemmap_alloc_block()
>>
>> When zero is true, memory that is allocated by memblock allocator is zeroed
>> (the current behavior), when argument is false, the memory is not zeroed.
>>
>> This change allows for optimizations where client knows when it is better
>> to zero memory: may be later when other CPUs are started, or may be client
>> is going to set every byte in the allocated memory, so no need to zero
>> memory beforehand.
>>
>> Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
>> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com>
>
> I think when you add a new argument that can adjust behavior, you
> should add the new argument but retain exactly the current behavior in
> the existing calls.
>
> Then later you can piece by piece change behavior, and document properly
> in the commit message what is happening and why the transformation is
> legal.
>
> Here, you are adding the new boolean to __earlyonly_bootmem_alloc() and
> then making sparse_mem_maps_populate_node() pass false, which changes
> behavior such that it doesn't get zero'd memory any more.
>
> Please make one change at a time. Otherwise review and bisection is
> going to be difficult.
>
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2017-05-03 15:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 19:19 [v2 0/5] parallelized "struct page" zeroing Pavel Tatashin
2017-03-24 19:19 ` [v2 1/5] sparc64: simplify vmemmap_populate Pavel Tatashin
2017-03-24 19:19 ` [v2 2/5] mm: defining memblock_virt_alloc_try_nid_raw Pavel Tatashin
2017-03-24 19:19 ` [v2 3/5] mm: add "zero" argument to vmemmap allocators Pavel Tatashin
2017-05-03 14:34 ` David Miller
2017-05-03 15:05 ` Pasha Tatashin [this message]
2017-03-24 19:19 ` [v2 4/5] mm: zero struct pages during initialization Pavel Tatashin
2017-03-24 19:19 ` [v2 5/5] mm: teach platforms not to zero struct pages memory Pavel Tatashin
2017-03-27 6:00 ` Heiko Carstens
2017-04-07 6:15 ` Aneesh Kumar K.V
2017-03-25 21:25 ` [v2 0/5] parallelized "struct page" zeroing Matthew Wilcox
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=3921e0c8-2c18-60e9-cc99-78dbed2dce90@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=sparclinux@vger.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 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).