From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (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 3vq2kV0vRgzDq7c for ; Fri, 24 Mar 2017 10:26:42 +1100 (AEDT) Date: Thu, 23 Mar 2017 16:26:38 -0700 From: Matthew Wilcox To: Pavel Tatashin Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.or Subject: Re: [v1 0/5] parallelized "struct page" zeroing Message-ID: <20170323232638.GB29134@bombadil.infradead.org> References: <1490310113-824438-1-git-send-email-pasha.tatashin@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1490310113-824438-1-git-send-email-pasha.tatashin@oracle.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: > When deferred struct page initialization feature is enabled, we get a > performance gain of initializing vmemmap in parallel after other CPUs are > started. However, we still zero the memory for vmemmap using one boot CPU. > This patch-set fixes the memset-zeroing limitation by deferring it as well. > > Here is example performance gain on SPARC with 32T: > base > https://hastebin.com/ozanelatat.go > > fix > https://hastebin.com/utonawukof.go > > As you can see without the fix it takes: 97.89s to boot > With the fix it takes: 46.91 to boot. How long does it take if we just don't zero this memory at all? We seem to be initialising most of struct page in __init_single_page(), so it seems like a lot of additional complexity to conditionally zero the rest of struct page.