[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171004084526.57uzy3t4ualwxdyt@dhcp22.suse.cz>
Date: Wed, 4 Oct 2017 10:45:26 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...cle.com>
Cc: linux-kernel@...r.kernel.org, sparclinux@...r.kernel.org,
linux-mm@...ck.org, linuxppc-dev@...ts.ozlabs.org,
linux-s390@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
x86@...nel.org, kasan-dev@...glegroups.com, borntraeger@...ibm.com,
heiko.carstens@...ibm.com, davem@...emloft.net,
willy@...radead.org, ard.biesheuvel@...aro.org,
mark.rutland@....com, will.deacon@....com, catalin.marinas@....com,
sam@...nborg.org, mgorman@...hsingularity.net,
steven.sistare@...cle.com, daniel.m.jordan@...cle.com,
bob.picco@...cle.com
Subject: Re: [PATCH v9 12/12] mm: stop zeroing memory during allocation in
vmemmap
On Tue 03-10-17 16:26:51, Pasha Tatashin wrote:
> Hi Michal,
>
> I decided not to merge these two patches, because in addition to sparc
> optimization move, we have this dependancies:
optimizations can and should go on top of the core patch.
> mm: zero reserved and unavailable struct pages
>
> must be before
>
> mm: stop zeroing memory during allocation in vmemmap.
>
> Otherwise, we can end-up with struct pages that are not zeroed properly.
Right and you can deal with it easily. Just introduce the
mm_zero_struct_page earlier along with its user in "stop zeroing ..."
I think that moving the zeroying in one go is more reasonable than
adding it to __init_single_page with misleading numbers and later
dropping the zeroying from the memmap path.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists