From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9489AC55186 for ; Fri, 24 Apr 2020 07:55:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4656520767 for ; Fri, 24 Apr 2020 07:55:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4656520767 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BC6E98E0005; Fri, 24 Apr 2020 03:55:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B77C68E0003; Fri, 24 Apr 2020 03:55:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8D338E0005; Fri, 24 Apr 2020 03:55:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0234.hostedemail.com [216.40.44.234]) by kanga.kvack.org (Postfix) with ESMTP id 8D5CB8E0003 for ; Fri, 24 Apr 2020 03:55:34 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 47868180AD81A for ; Fri, 24 Apr 2020 07:55:34 +0000 (UTC) X-FDA: 76741988988.28.heart47_87e517eb7ed63 X-HE-Tag: heart47_87e517eb7ed63 X-Filterd-Recvd-Size: 3714 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Apr 2020 07:55:33 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D04A6AAC7; Fri, 24 Apr 2020 07:55:30 +0000 (UTC) Subject: Re: [RFC PATCH 4/4] mm: Add PG_zero support To: David Hildenbrand , Matthew Wilcox , Andrew Morton Cc: Alexander Duyck , Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , Dan Williams , Dave Hansen , Michal Hocko , Alex Williamson References: <20200412090945.GA19582@open-light-1.localdomain> <20200412101223.GK21484@bombadil.infradead.org> <5eb37d79-6420-fcb9-2b4c-6cc6194afcd9@linux.intel.com> <20200413140537.eb674579cf8c71b4e20581ab@linux-foundation.org> <344a3a78-62ad-48fe-40cf-18993175d1e0@suse.cz> <20200423173700.b2c954b3960e4379a4f82e80@linux-foundation.org> <20200424004152.GD13910@bombadil.infradead.org> From: Vlastimil Babka Message-ID: <09885eda-9772-4228-dece-3dfd42840580@suse.cz> Date: Fri, 24 Apr 2020 09:55:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 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 > 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.