From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752851AbdEOUov (ORCPT ); Mon, 15 May 2017 16:44:51 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:23236 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751034AbdEOUos (ORCPT ); Mon, 15 May 2017 16:44:48 -0400 Subject: Re: [v3 0/9] parallelized "struct page" zeroing To: Michal Hocko Cc: 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, davem@davemloft.net References: <1494003796-748672-1-git-send-email-pasha.tatashin@oracle.com> <20170509181234.GA4397@dhcp22.suse.cz> <20170515193817.GC7551@dhcp22.suse.cz> From: Pasha Tatashin Message-ID: <9b3d68aa-d2b6-2b02-4e75-f8372cbeb041@oracle.com> Date: Mon, 15 May 2017 16:44:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170515193817.GC7551@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/15/2017 03:38 PM, Michal Hocko wrote: > On Mon 15-05-17 14:12:10, Pasha Tatashin wrote: >> Hi Michal, >> >> After looking at your suggested memblock_virt_alloc_core() change again, I >> decided to keep what I have. I do not want to inline >> memblock_virt_alloc_internal(), because it is not a performance critical >> path, and by inlining it we will unnecessarily increase the text size on all >> platforms. > > I do not insist but I would really _prefer_ if the bool zero argument > didn't proliferate all over the memblock API. Sure, I will remove zero boolean argument from memblock_virt_alloc_internal(), and do memset() calls inside callers. > >> Also, because it will be very hard to make sure that no platform regresses >> by making memset() default in _memblock_virt_alloc_core() (as I already >> showed last week at least sun4v SPARC64 will require special changes in >> order for this to work), I decided to make it available only for "deferred >> struct page init" case. As, what is already in the patch. > > I do not think this is the right approach. Your measurements just show > that sparc could have a more optimized memset for small sizes. If you > keep the same memset only for the parallel initialization then you > just hide this fact. I wouldn't worry about other architectures. All > sane architectures should simply work reasonably well when touching a > single or only few cache lines at the same time. If some arches really > suffer from small memsets then the initialization should be driven by a > specific ARCH_WANT_LARGE_PAGEBLOCK_INIT rather than making this depend > on DEFERRED_INIT. Or if you are too worried then make it opt-in and make > it depend on ARCH_WANT_PER_PAGE_INIT and make it enabled for x86 and > sparc after memset optimization. OK, I will think about this. I do not really like adding new configs because they tend to clutter the code. This is why, I wanted to rely on already existing config that I know benefits all platforms that use it. Eventually, "CONFIG_DEFERRED_STRUCT_PAGE_INIT" is going to become the default everywhere, as there should not be a drawback of using it even on small machines. Pasha