On 4/24/20 9:28 AM, David Hildenbrand wrote: > On 24.04.20 02:41, Matthew Wilcox wrote: >> On Thu, Apr 23, 2020 at 05:37:00PM -0700, Andrew Morton wrote: >>> On Wed, 22 Apr 2020 16:09:00 +0200 Vlastimil Babka <vbabka@xxxxxxx> wrote: >>>> Heh, I was quite sure that this is not the first time background zeroing is >>>> proposed, so I went to google for it... and found that one BSD kernel actually >>>> removed this functionality in 2016 [1] and this was one of the reasons. >>>> >>>> [1] >>>> https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/afd2da4dc9056ea79cdf15e8a9386a3d3998f33e >>> >>> Interesting. >>> >>> However this: >>> >>> - Pre-zeroing a page leads to a cold-cache case on-use, forcing the fault >>> source (e.g. a userland program) to actually get the data from main >>> memory in its likely immediate use of the faulted page, reducing >>> performance. >>> >>> implies that BSD was zeroing with non-temporal stores which bypass the >>> CPU cache. And which presumably invalidate any part of the target >>> memory which was already in cache. We wouldn't do it that way so >>> perhaps the results would differ. >> >> Or just that the page was zeroed far enough in advance that it fell out >> of cache naturally. Agreed. >> I know Arjan looked at zeroing on free instead of zeroing on alloc, >> and that didn't get merged (or even submitted afaik), so presumably the >> results weren't good. > > We do have INIT_ON_FREE_DEFAULT_ON > > via > > commit 6471384af2a6530696fc0203bafe4de41a23c9ef > Author: Alexander Potapenko <glider@xxxxxxxxxx> > Date: Thu Jul 11 20:59:19 2019 -0700 > > mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options > > which seems to do exactly that (although for a different use case) Yeah, except the security use case wants to do that immediately, while the proposal here is a background thread.
