Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1252628imm; Wed, 25 Jul 2018 14:31:35 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfvte5xPU7P1UeRaspaX6GrqLsCJmpcwutXRYYmv7rF84ROyNUR2fCf/MqlXvFfhGo2hyiq X-Received: by 2002:a62:401:: with SMTP id 1-v6mr23641366pfe.28.1532554295111; Wed, 25 Jul 2018 14:31:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532554295; cv=none; d=google.com; s=arc-20160816; b=uhDRTXi4jdVulPGFk9j7HMHzyfcZc9LaCIwkN89Q6dww19DuTfxFP+CkksvTt7JOZT o9rSEbYyamNld3+EJNUDZHxc/ptKYUF2kqwPsKXBCcRmcTGVjlcC2hXcvuJYNYLBYwFG 8+Bq1s8qmo5d0+va8zNRdCLEI77d2rdMiH9uLfUXcwflYdI2908S8gPXZAJiCWyQkjV4 SKd3MjOSSJWSw2nYV6Lces4XVcs6eMcCYMezF33mYysXINk0YIxC0KWOFeMipWw/aZmY VmUIteHBtcvp5WU82oW+FCIRGllwxLJM2a/jE0LzoqB7agXcOGoS8M8PX5U79MLDSnlp ZWcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=qwZsqTF7oWhXFkZ2ViYJAKQYZhGUN42bneLvMZN4Ias=; b=XxqWQy1X95gML0IvPLoyduqCtZmLxa5kkn3L2vy/P6DOG7s6TAYc/3MBu3hWisv1hI d6cboiXjehDsC9HAv/TSAgkx8eWBwzmNLrJibMSO/9G8cbvUHuGc+rLwV5JeB441qmrz bUkUh9mEM3Wz17YvUxhD1ZqZ0LSzZqcd3qF1A9FxXanvf+v8Z05t0HxD3v+dVfY6fmru 7wuTtK6H7hit+hCw3RGMT0dZEpkDADOBsVCMsFczgd5vM5XJCGiHnZ7EAp57ajF7qEeS 1Z8xfex3G0oT0/ON0nmED3oO9IqtgVeo9zoepLUsokOQIJoio0eBWqnITUYcsR4T10wK CmuQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b6-v6si13056359pls.347.2018.07.25.14.31.19; Wed, 25 Jul 2018 14:31:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731373AbeGYWno (ORCPT + 99 others); Wed, 25 Jul 2018 18:43:44 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:58074 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731174AbeGYWno (ORCPT ); Wed, 25 Jul 2018 18:43:44 -0400 Received: from localhost.localdomain (c-24-4-125-7.hsd1.ca.comcast.net [24.4.125.7]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id DF877BBF; Wed, 25 Jul 2018 21:30:08 +0000 (UTC) Date: Wed, 25 Jul 2018 14:30:07 -0700 From: Andrew Morton To: Pavel Tatashin Cc: Steven Sistare , Daniel Jordan , LKML , kirill.shutemov@linux.intel.com, Michal Hocko , Linux Memory Management List , dan.j.williams@intel.com, jack@suse.cz, jglisse@redhat.com, Souptick Joarder , bhe@redhat.com, gregkh@linuxfoundation.org, Vlastimil Babka , Wei Yang , dave.hansen@intel.com, rientjes@google.com, mingo@kernel.org, osalvador@techadventures.net, abdhalee@linux.vnet.ibm.com, mpe@ellerman.id.au Subject: Re: [PATCH 2/3] mm: calculate deferred pages after skipping mirrored memory Message-Id: <20180725143007.25d5bff352872aba90ca731b@linux-foundation.org> In-Reply-To: References: <20180724235520.10200-1-pasha.tatashin@oracle.com> <20180724235520.10200-3-pasha.tatashin@oracle.com> <20180724183142.d20798b43fd1215f6165649c@linux-foundation.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 24 Jul 2018 21:46:25 -0400 Pavel Tatashin wrote: > > > +static inline bool defer_init(int nid, unsigned long pfn, unsigned long end_pfn) > > > { > > > + static unsigned long prev_end_pfn, nr_initialised; > > > > So answer me quick, what happens with a static variable in an inlined > > function? Is there one copy kernel-wide? One copy per invocation > > site? One copy per compilation unit? > > > > Well I didn't know so I wrote a little test. One copy per compilation > > unit (.o file), it appears. > > > > It's OK in this case because the function is in .c (and has only one > > call site). But if someone moves it into a header and uses it from a > > different .c file, they have problems. > > > > So it's dangerous, and poor practice. I'll make this non-static > > __meminit. > > I agree, it should not be moved to header it is dangerous. > > But, on the other hand this is a hot-path. memmap_init_zone() might > need to go through billions of struct pages early in boot, and I did > not want us to waste time on function calls. With defer_init() this is > not a problem, because if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set > memmap_init_zone() won't have much work to do, but for > overlap_memmap_init() this is a problem, especially because I expect > compiler to optimize the pfn dereference usage in inline function. Well. The compiler will just go and inline defer_init() anwyay - it has a single callsite and is in the same __meminint section as its calling function. My gcc-7.2.0 does this. Marking it noninline __meminit is basically syntactic fluff designed to encourage people to think twice. > > > > --- a/mm/page_alloc.c~mm-calculate-deferred-pages-after-skipping-mirrored-memory-fix > > +++ a/mm/page_alloc.c > > @@ -309,7 +309,8 @@ static inline bool __meminit early_page_ > > * Returns true when the remaining initialisation should be deferred until > > * later in the boot cycle when it can be parallelised. > > */ > > -static inline bool defer_init(int nid, unsigned long pfn, unsigned long end_pfn) > > +static bool __meminit > > +defer_init(int nid, unsigned long pfn, unsigned long end_pfn) > > { > > static unsigned long prev_end_pfn, nr_initialised; > > > > > > Also, what locking protects these statics? Our knowledge that this > > code is single-threaded, presumably? > > Correct, this is called only from "context == MEMMAP_EARLY", way > before smp_init(). Might be worth a little comment to put readers minds at ease.