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. > > 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) -- Thanks, David / dhildenb
