From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932066AbdEJSAc (ORCPT ); Wed, 10 May 2017 14:00:32 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:42364 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753552AbdEJSAa (ORCPT ); Wed, 10 May 2017 14:00:30 -0400 Date: Wed, 10 May 2017 14:00:26 -0400 (EDT) Message-Id: <20170510.140026.1367439672848112283.davem@davemloft.net> To: willy@infradead.org Cc: mhocko@kernel.org, pasha.tatashin@oracle.com, linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, borntraeger@de.ibm.com, heiko.carstens@de.ibm.com Subject: Re: [v3 0/9] parallelized "struct page" zeroing From: David Miller In-Reply-To: <20170510171703.GC1590@bombadil.infradead.org> References: <20170510145726.GM31466@dhcp22.suse.cz> <20170510.111943.1940354761418085760.davem@davemloft.net> <20170510171703.GC1590@bombadil.infradead.org> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 10 May 2017 10:19:00 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Matthew Wilcox Date: Wed, 10 May 2017 10:17:03 -0700 > On Wed, May 10, 2017 at 11:19:43AM -0400, David Miller wrote: >> From: Michal Hocko >> Date: Wed, 10 May 2017 16:57:26 +0200 >> >> > Have you measured that? I do not think it would be super hard to >> > measure. I would be quite surprised if this added much if anything at >> > all as the whole struct page should be in the cache line already. We do >> > set reference count and other struct members. Almost nobody should be >> > looking at our page at this time and stealing the cache line. On the >> > other hand a large memcpy will basically wipe everything away from the >> > cpu cache. Or am I missing something? >> >> I guess it might be clearer if you understand what the block >> initializing stores do on sparc64. There are no memory accesses at >> all. >> >> The cpu just zeros out the cache line, that's it. >> >> No L3 cache line is allocated. So this "wipe everything" behavior >> will not happen in the L3. > > There's either something wrong with your explanation or my reading > skills :-) > > "There are no memory accesses" > "No L3 cache line is allocated" > > You can have one or the other ... either the CPU sends a cacheline-sized > write of zeroes to memory without allocating an L3 cache line (maybe > using the store buffer?), or the CPU allocates an L3 cache line and sets > its contents to zeroes, probably putting it in the last way of the set > so it's the first thing to be evicted if not touched. There is no conflict in what I said. Only an L2 cache line is allocated and cleared. L3 is left alone.