Received: by 10.213.65.68 with SMTP id h4csp1162326imn; Mon, 26 Mar 2018 01:54:40 -0700 (PDT) X-Google-Smtp-Source: AG47ELsHkxRLLhSZIOX1eSwx0R2leZpbLj8IBwenAuD2dXxHdX6Y/DOj05ZaZfcYLA6Y5aLcVGSU X-Received: by 2002:a17:902:42a3:: with SMTP id h32-v6mr38799885pld.231.1522054480104; Mon, 26 Mar 2018 01:54:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522054480; cv=none; d=google.com; s=arc-20160816; b=vzWI2IZsETjfphBATopsHEEngfVrxO7bfph7EcYUpx+Uwl4pGUs7SWXvIhQjtExcbe 75IsAtdLqBlBHefyl7koiqxL5aWUU68x/ayPk5wf1EHDq9lQ0HhOBDgIE2NyeAXbAmNt KDgLLUTx377oV276KmUfR0p+cDjB5BGtgG/zy3a5IsrJLYIKtdtu7j6gfKR/edHmrRI/ 7aShmAmqzRDcdKTuWHxhv0muj/0QEWY3XG3noIiclniCk4cWrckszVi0w5ENfV3+7FDh 4ziqSBjAlHv6kYVkYPye/8aBSdRs1y3uHNoBHgmZ8pfwgnv9VoLI6HyBTPIirGVMvvw3 /ODg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=vTwpiCE9DnQxZf/EmnAJgGFUPt+v4iLUYof6pe6joGw=; b=Zj7dVd9mVIVGll7v/nCbgDeSXuleFe57tyJxVk2g+8LaLkljwOM/gWnyfvqqLzmjvE DiwoHl+4isqOqru+OOXfbwyONbrQaaxJzUN3aa00Yr6I1hOfYI4GfmlZsIfRQwBug1MM XFNmemVikQUKE0VKY0qtxccXN+r7JlKEbuP2EdYtIpFWdDPpdKlpHe/CvJK53ZcrzhcV JEG2yR8oWcHLM655h3bS8ZY1gjdF9IIXkvNfSAFt5oauACNJNqC0hdznTmc1KNZWRrtr EjbuAnfhsHh/EhAqZTpbvz8oB99QnDbSsun/KZGBMfzulwNA+hOWPo2+3Iba3uvVP/BB jJMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=fylNZuiY; 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 61-v6si14266333plr.136.2018.03.26.01.54.25; Mon, 26 Mar 2018 01:54:40 -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; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=fylNZuiY; 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 S1751355AbeCZIxZ (ORCPT + 99 others); Mon, 26 Mar 2018 04:53:25 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:40087 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750955AbeCZIxX (ORCPT ); Mon, 26 Mar 2018 04:53:23 -0400 Received: by mail-wm0-f67.google.com with SMTP id x4so1558320wmh.5 for ; Mon, 26 Mar 2018 01:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=vTwpiCE9DnQxZf/EmnAJgGFUPt+v4iLUYof6pe6joGw=; b=fylNZuiYXiq3svjb9NYywy9Q5hO9FbrHMoQvrQ3C0a/T29I8gTPJguA+W5/HlQcL1F FEPpvDbxG09Ow3hKkP1aWO3rlCuciZfKEoCWFC1LqKc9At6BsusCAXGA8P/AMi2RiR6X AdlAQuYb6Zr+xsbfsKoOY/uQrsoV5vIjKuAik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=vTwpiCE9DnQxZf/EmnAJgGFUPt+v4iLUYof6pe6joGw=; b=lsqAID+87gh1XM1mAogCGf8utxaTZiUYS7P5zLaKdXSRrfcnAzneErBfwJq2lA7PfF o/vJ1B4Ih77NUwxRIqa2SaF5cDkwE2Uhi2JijPNpg1CYZgZ9kclIBMhDg0gUkHjsMzYo TvmtYgx/F5bpqy2cINQOhb0NTkmMQQFFIa839g3nt5U+lsIQnq/sF9YKVTUcCxYoVj+R I1laqL6q1CdgRfEpFO+1DoVc6j0QgqJz1CbN1vjLaRwBFFtsk8SaSfEAySd15b7UoBRu MiTnAMr5fDRkQ6hAh7Fqnz/lcBf65h4uK/4FBR1DA2jIqhKpSYkV9d1HI+uTqas6nvXS MYJA== X-Gm-Message-State: AElRT7HLQ3tmQ8AhjV8oulNI6+YmzQhoItkQ0EKRfoyJMKKyaOkay8Z3 yB+ct4MRRB5whMq0oesCQ9ONTw== X-Received: by 10.28.94.210 with SMTP id s201mr2564921wmb.140.1522054402026; Mon, 26 Mar 2018 01:53:22 -0700 (PDT) Received: from andrea (host187-49-dynamic.250-95-r.retail.telecomitalia.it. [95.250.49.187]) by smtp.gmail.com with ESMTPSA id c14sm13824769wrd.17.2018.03.26.01.53.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 01:53:21 -0700 (PDT) Date: Mon, 26 Mar 2018 10:53:13 +0200 From: Andrea Parri To: Yury Norov Cc: "Paul E. McKenney" , Chris Metcalf , Christopher Lameter , Russell King - ARM Linux , Mark Rutland , Steven Rostedt , Mathieu Desnoyers , Catalin Marinas , Will Deacon , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] smp: introduce kick_active_cpus_sync() Message-ID: <20180326085313.GA4016@andrea> References: <20180325175004.28162-1-ynorov@caviumnetworks.com> <20180325175004.28162-3-ynorov@caviumnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180325175004.28162-3-ynorov@caviumnetworks.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Yury, On Sun, Mar 25, 2018 at 08:50:04PM +0300, Yury Norov wrote: > kick_all_cpus_sync() forces all CPUs to sync caches by sending broadcast IPI. > If CPU is in extended quiescent state (idle task or nohz_full userspace), this > work may be done at the exit of this state. Delaying synchronization helps to > save power if CPU is in idle state and decrease latency for real-time tasks. > > This patch introduces kick_active_cpus_sync() and uses it in mm/slab and arm64 > code to delay syncronization. > > For task isolation (https://lkml.org/lkml/2017/11/3/589), IPI to the CPU running > isolated task would be fatal, as it breaks isolation. The approach with delaying > of synchronization work helps to maintain isolated state. > > I've tested it with test from task isolation series on ThunderX2 for more than > 10 hours (10k giga-ticks) without breaking isolation. > > Signed-off-by: Yury Norov > --- > arch/arm64/kernel/insn.c | 2 +- > include/linux/smp.h | 2 ++ > kernel/smp.c | 24 ++++++++++++++++++++++++ > mm/slab.c | 2 +- > 4 files changed, 28 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c > index 2718a77da165..9d7c492e920e 100644 > --- a/arch/arm64/kernel/insn.c > +++ b/arch/arm64/kernel/insn.c > @@ -291,7 +291,7 @@ int __kprobes aarch64_insn_patch_text(void *addrs[], u32 insns[], int cnt) > * synchronization. > */ > ret = aarch64_insn_patch_text_nosync(addrs[0], insns[0]); > - kick_all_cpus_sync(); > + kick_active_cpus_sync(); > return ret; > } > } > diff --git a/include/linux/smp.h b/include/linux/smp.h > index 9fb239e12b82..27215e22240d 100644 > --- a/include/linux/smp.h > +++ b/include/linux/smp.h > @@ -105,6 +105,7 @@ int smp_call_function_any(const struct cpumask *mask, > smp_call_func_t func, void *info, int wait); > > void kick_all_cpus_sync(void); > +void kick_active_cpus_sync(void); > void wake_up_all_idle_cpus(void); > > /* > @@ -161,6 +162,7 @@ smp_call_function_any(const struct cpumask *mask, smp_call_func_t func, > } > > static inline void kick_all_cpus_sync(void) { } > +static inline void kick_active_cpus_sync(void) { } > static inline void wake_up_all_idle_cpus(void) { } > > #ifdef CONFIG_UP_LATE_INIT > diff --git a/kernel/smp.c b/kernel/smp.c > index 084c8b3a2681..0358d6673850 100644 > --- a/kernel/smp.c > +++ b/kernel/smp.c > @@ -724,6 +724,30 @@ void kick_all_cpus_sync(void) > } > EXPORT_SYMBOL_GPL(kick_all_cpus_sync); > > +/** > + * kick_active_cpus_sync - Force CPUs that are not in extended > + * quiescent state (idle or nohz_full userspace) sync by sending > + * IPI. Extended quiescent state CPUs will sync at the exit of > + * that state. > + */ > +void kick_active_cpus_sync(void) > +{ > + int cpu; > + struct cpumask kernel_cpus; > + > + smp_mb(); (A general remark only:) checkpatch.pl should have warned about the fact that this barrier is missing an accompanying comment (which accesses are being "ordered", what is the pairing barrier, etc.). Moreover if, as your reply above suggested, your patch is relying on "implicit barriers" (something I would not recommend) then even more so you should comment on these requirements. This could: (a) force you to reason about the memory ordering stuff, (b) easy the task of reviewing and adopting your patch, (c) easy the task of preserving those requirements (as implementations changes). Andrea > + > + cpumask_clear(&kernel_cpus); > + preempt_disable(); > + for_each_online_cpu(cpu) { > + if (!rcu_eqs_special_set(cpu)) > + cpumask_set_cpu(cpu, &kernel_cpus); > + } > + smp_call_function_many(&kernel_cpus, do_nothing, NULL, 1); > + preempt_enable(); > +} > +EXPORT_SYMBOL_GPL(kick_active_cpus_sync); > + > /** > * wake_up_all_idle_cpus - break all cpus out of idle > * wake_up_all_idle_cpus try to break all cpus which is in idle state even > diff --git a/mm/slab.c b/mm/slab.c > index 324446621b3e..678d5dbd6f46 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -3856,7 +3856,7 @@ static int __do_tune_cpucache(struct kmem_cache *cachep, int limit, > * cpus, so skip the IPIs. > */ > if (prev) > - kick_all_cpus_sync(); > + kick_active_cpus_sync(); > > check_irq_on(); > cachep->batchcount = batchcount; > -- > 2.14.1 >