From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753413AbdEJPTr (ORCPT ); Wed, 10 May 2017 11:19:47 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:41142 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752078AbdEJPTp (ORCPT ); Wed, 10 May 2017 11:19:45 -0400 Date: Wed, 10 May 2017 11:19:43 -0400 (EDT) Message-Id: <20170510.111943.1940354761418085760.davem@davemloft.net> To: mhocko@kernel.org Cc: 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: <20170510145726.GM31466@dhcp22.suse.cz> References: <20170510072419.GC31466@dhcp22.suse.cz> <3f5f1416-aa91-a2ff-cc89-b97fcaa3e4db@oracle.com> <20170510145726.GM31466@dhcp22.suse.cz> 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 07:38:15 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.