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 BD01EC5518B for ; Wed, 22 Apr 2020 14:09:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8B97820787 for ; Wed, 22 Apr 2020 14:09:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B97820787 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 1E0428E0026; Wed, 22 Apr 2020 10:09:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 191528E0003; Wed, 22 Apr 2020 10:09:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A7868E0026; Wed, 22 Apr 2020 10:09:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id E028C8E0003 for ; Wed, 22 Apr 2020 10:09:06 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 98D9A180AD80F for ; Wed, 22 Apr 2020 14:09:06 +0000 (UTC) X-FDA: 76735672692.15.toes99_4f80464e2781d X-HE-Tag: toes99_4f80464e2781d X-Filterd-Recvd-Size: 2936 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 14:09:06 +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 817B3ABCF; Wed, 22 Apr 2020 14:09:02 +0000 (UTC) Subject: Re: [RFC PATCH 4/4] mm: Add PG_zero support To: Andrew Morton , Alexander Duyck Cc: Matthew Wilcox , Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , Dan Williams , Dave Hansen , David Hildenbrand , 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> From: Vlastimil Babka Message-ID: <344a3a78-62ad-48fe-40cf-18993175d1e0@suse.cz> Date: Wed, 22 Apr 2020 16:09:00 +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: <20200413140537.eb674579cf8c71b4e20581ab@linux-foundation.org> 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/13/20 11:05 PM, Andrew Morton wrote: > On Mon, 13 Apr 2020 08:11:59 -0700 Alexander Duyck 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? >