Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751794AbdG0VAW (ORCPT ); Thu, 27 Jul 2017 17:00:22 -0400 Received: from mail.efficios.com ([167.114.142.141]:56528 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751596AbdG0VAS (ORCPT ); Thu, 27 Jul 2017 17:00:18 -0400 Date: Thu, 27 Jul 2017 21:02:24 +0000 (UTC) From: Mathieu Desnoyers To: "Paul E. McKenney" , Avi Kivity Cc: maged michael , Andrew Hunter , gromer , linux-kernel , Peter Zijlstra Message-ID: <1546253326.29115.1501189344518.JavaMail.zimbra@efficios.com> In-Reply-To: <1035920775.29109.1501189118277.JavaMail.zimbra@efficios.com> References: <20170727181250.GA20183@linux.vnet.ibm.com> <5c8c6946-ce3a-6183-76a2-027823a9948a@scylladb.com> <20170727194322.GL3730@linux.vnet.ibm.com> <5fe39d32-5fc1-3a59-23fc-9bdb1d90edf9@scylladb.com> <20170727203706.GO3730@linux.vnet.ibm.com> <1035920775.29109.1501189118277.JavaMail.zimbra@efficios.com> Subject: Re: Udpated sys_membarrier() speedup patch, FYI MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.141] X-Mailer: Zimbra 8.7.9_GA_1794 (ZimbraWebClient - FF52 (Linux)/8.7.9_GA_1794) Thread-Topic: Udpated sys_membarrier() speedup patch, FYI Thread-Index: Zq6dVh+YeLSLW0CGGUGiA/6gU3H9s3wIh/1O Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1433 Lines: 57 ----- On Jul 27, 2017, at 4:58 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote: > ----- On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paulmck@linux.vnet.ibm.com > wrote: > >> On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote: [...] >>> >+ >>> >+ this_cpu = raw_smp_processor_id(); >>> >+ for_each_online_cpu(cpu) { >>> >+ struct task_struct *p; >>> >+ >>> >+ if (cpu == this_cpu) >>> >+ continue; >>> >+ rcu_read_lock(); >>> >+ p = task_rcu_dereference(&cpu_rq(cpu)->curr); >>> >+ if (p && p->mm == current->mm) >>> >+ __cpumask_set_cpu(cpu, tmpmask); >>> >>> This gets you some false positives, if the CPU idled then mm will >>> not have changed. >> >> Good point! The battery-powered embedded guys would probably prefer >> we not needlessly IPI idle CPUs. We cannot rely on RCU's dyntick-idle >> state in nohz_full cases. Not sure if is_idle_task() can be used >> safely, given things like play_idle(). > > Would changing the check in this loop to: > > if (p && !is_idle_task(p) && p->mm == current->mm) { > > work for you ? Avi, is there an optimization that allows current->mm to be non-null when the idle task is scheduled that I am missing ? I would have expected current->mm to be always NULL for idle tasks. Thanks, Mathieu > > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com