From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: linux-next: Tree for Feb 4 Date: Thu, 5 Feb 2015 06:37:07 -0800 Message-ID: <20150205143707.GX5370@linux.vnet.ibm.com> References: <20150204215357.GL5370@linux.vnet.ibm.com> <11131483.LrRNxJumiL@vostro.rjw.lan> <20150204235115.GP5370@linux.vnet.ibm.com> <20150205001019.GA12362@linux.vnet.ibm.com> <20150205005716.GS5370@linux.vnet.ibm.com> <20150205015144.GT5370@linux.vnet.ibm.com> <54D3186F.7030500@sr71.net> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <54D3186F.7030500@sr71.net> Sender: linux-kernel-owner@vger.kernel.org To: Dave Hansen Cc: sedat.dilek@gmail.com, "Rafael J. Wysocki" , "Rafael J. Wysocki" , linux-next , LKML , Stephen Rothwell , Kristen Carlson Accardi , "H. Peter Anvin" , Rik van Riel , Mel Gorman , Steven Rostedt List-Id: linux-next.vger.kernel.org On Wed, Feb 04, 2015 at 11:14:55PM -0800, Dave Hansen wrote: > On 02/04/2015 05:53 PM, Sedat Dilek wrote: > > The architecture-specific switch_mm() function can be called by offline > > CPUs, but includes event tracing, which cannot be legally carried out > > on offline CPUs. This results in a lockdep-RCU splat. This commit fixes > > this splat by omitting the tracing when the CPU is offline. > ... > >>> >> > load_cr3(next->pgd); > >>> >> > - trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH, TLB_FLUSH_ALL); > >>> >> > + if (cpu_online(smp_processor_id())) > >>> >> > + trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH, TLB_FLUSH_ALL); > > Is this, perhaps, something that we should be doing in the generic trace > code so that all of the trace users don't have to worry about it? Also, > this patch will add overhead to the code when tracing is off. It would > be best if we could manage to make the cpu_online() check only in the > cases where the tracepoint is on. I considered doing this in the _rcuidle piece of the trace code, but unlike the RCU idle exit/entry in the _rcuidle stuff, the work required to get through the RCU online/offline code is pretty heavyweight. You end up having 16 CPUs contending for an rcu_node lock, for example. But maybe you are instead suggesting pushing only the cpu_online() check into the trace infrastructure. If so, fair point, and I will take a look at this. Thanx, Paul