From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752916AbdEPXwA (ORCPT ); Tue, 16 May 2017 19:52:00 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:53867 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751730AbdEPXv6 (ORCPT ); Tue, 16 May 2017 19:51:58 -0400 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> Organization: IBM Australia Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-MML: disable x-cbid: 17051623-0040-0000-0000-00000318766E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051623-0041-0000-0000-00000C911D96 Message-Id: <1494978657.21847.74.camel@au1.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-16_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705160191 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.