From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3wSDkq0vynzDqNw for ; Wed, 17 May 2017 09:52:02 +1000 (AEST) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4GNmlpx111737 for ; Tue, 16 May 2017 19:51:57 -0400 Received: from e23smtp04.au.ibm.com (e23smtp04.au.ibm.com [202.81.31.146]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ag7ewhbf2-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 16 May 2017 19:51:57 -0400 Received: from localhost by e23smtp04.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 17 May 2017 09:51:54 +1000 Received: from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119]) by d23relay06.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v4GNpi0v57802934 for ; Wed, 17 May 2017 09:51:52 +1000 Received: from d23av05.au.ibm.com (localhost [127.0.0.1]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id v4GNpJAH026012 for ; Wed, 17 May 2017 09:51:19 +1000 Subject: Re: [v3 0/9] parallelized "struct page" zeroing From: Benjamin Herrenschmidt Reply-To: benh@au1.ibm.com To: David Miller , pasha.tatashin@oracle.com Cc: linux-s390@vger.kernel.org, borntraeger@de.ibm.com, heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, mhocko@kernel.org, linux-mm@kvack.org, sparclinux@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Date: Wed, 17 May 2017 09:50:57 +1000 In-Reply-To: <20170512.133742.2144484253675877904.davem@davemloft.net> References: <65b8a658-76d1-0617-ece8-ff7a3c1c4046@oracle.com> <20170512.125708.475573831936972365.davem@davemloft.net> <6da8d4a6-3332-8331-c329-b05efd88a70d@oracle.com> <20170512.133742.2144484253675877904.davem@davemloft.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1494978657.21847.74.camel@au1.ibm.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 2017-05-12 at 13:37 -0400, David Miller wrote: > > Right now it is larger, but what I suggested is to add a new optimized > > routine just for this case, which would do STBI for 64-bytes but > > without membar (do membar at the end of memmap_init_zone() and > > deferred_init_memmap() > > > > #define struct_page_clear(page)                                 \ > >          __asm__ __volatile__(                                   \ > >          "stxa   %%g0, [%0]%2\n"                                 \ > >          "stxa   %%xg0, [%0 + %1]%2\n"                           \ > >          : /* No output */                                       \ > >          : "r" (page), "r" (0x20), "i"(ASI_BLK_INIT_QUAD_LDD_P)) > > > > And insert it into __init_single_page() instead of memset() > > > > The final result is 4.01s/T which is even faster compared to current > > 4.97s/T > > Ok, indeed, that would work. On ppc64, that might not. We have a dcbz instruction that clears an entire cache line at once. That's what we use for memset's and page clearing. However, 64 bytes is half a cache line on modern processors so we can't use it with that semantic and would have to fallback to the slower stores. Cheers, Ben.