On 4/13/20 11:05 PM, Andrew Morton wrote: > On Mon, 13 Apr 2020 08:11:59 -0700 Alexander Duyck <alexander.h.duyck@xxxxxxxxxxxxxxx> wrote: > >> In addition, unlike madvising the page away there is a pretty >> significant performance penalty for having to clear the page a second >> time when the page is split or merged. > > I wonder if there might be an issue with increased memory traffic (and > increased energy consumption, etc). If a page is zeroed immediately > before getting data written into it (eg, plain old file write(), > anonymous pagefault) then we can expect that those 4096 zeroes will be > in CPU cache and mostly not written back. But if that page was zeroed > a "long" time ago, the caches will probably have been written back. > Net result: we go from 4k of memory traffic for a 4k page up to 8k of > memory traffic? 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 > Also, the name CONFIG_ZERO_PAGE sounds like it has something to do with > the long established "zero page". Confusing. CONFIG_PREZERO_PAGE, > maybe? >
