From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752373AbdEPNHQ (ORCPT ); Tue, 16 May 2017 09:07:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:39890 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750765AbdEPNHL (ORCPT ); Tue, 16 May 2017 09:07:11 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 784D723962 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Tue, 16 May 2017 09:07:08 -0400 From: Steven Rostedt To: "Paul E. McKenney" Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Masami Hiramatsu Subject: Re: Use case for TASKS_RCU Message-ID: <20170516090708.35fd8a12@gandalf.local.home> In-Reply-To: <20170516122354.GB3956@linux.vnet.ibm.com> References: <20170515182354.GA25440@linux.vnet.ibm.com> <20170516062233.tyz7ze7ilmbkxtjc@gmail.com> <20170516122354.GB3956@linux.vnet.ibm.com> X-Mailer: Claws Mail 3.14.0 (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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 16 May 2017 05:23:54 -0700 "Paul E. McKenney" wrote: > On Tue, May 16, 2017 at 08:22:33AM +0200, Ingo Molnar wrote: > > > > * Paul E. McKenney wrote: > > > > > Hello! > > > > > > The question of the use case for TASKS_RCU came up, and here is my > > > understanding. Steve will not be shy about correcting any misconceptions > > > I might have. ;-) > > > > > > The use case is to support freeing of trampolines used in tracing/probing > > > in CONFIG_PREEMPT=y kernels. It is necessary to wait until any task > > > executing in the trampoline in question has left it, taking into account > > > that the trampoline's code might be interrupted and preempted. However, > > > the code in the trampolines is guaranteed never to context switch. > > > > > > Note that in CONFIG_PREEMPT=n kernels, synchronize_sched() suffices. > > > It is therefore tempting to think in terms of disabling preemption across > > > the trampolines, but there is apparently not enough room to accommodate > > > the needed preempt_disable() and preempt_enable() in the code invoking > > > the trampoline, and putting the preempt_disable() and preempt_enable() > > > in the trampoline itself fails because of the possibility of preemption > > > just before the preempt_disable() and just after the preempt_enable(). > > > Similar reasoning rules out use of rcu_read_lock() and rcu_read_unlock(). > > > > So how was this solved before TASKS_RCU? Also, nothing uses call_rcu_tasks() at > > the moment, so it's hard for me to review its users. What am I missing? > > Before TASKS_RCU, the trampolines were just leaked when CONFIG_PREEMPT=y. Actually, things simply were not implemented. This is why optimized kprobes is dependent on !CONFIG_PREEMPT. In fact, we can now optimize kprobes on CONFIG_PREEMPT with this utility. Right Masami? With ftrace, perf and other "dynamic" users (where the ftrace_ops was created via a kmalloc), would not get the benefit of being called directly. They all needed to have their mcount/fentry's call a static trampoline that disabled preemption before calling the callback. This static trampoline is shared by all, so even if perf was the only callback for the function, it had to call this trampoline that iterated through all registered ftrace_ops to see which one had a callback for the given function. With this utility, perf not only gets the benefit of not having to use that static loop trampoline, it can even have its own trampoline created that doesn't even need to do the check if perf wants this function or not, as the only way the trampoline is called, is if perf wanted it. > > Current mainline kernel/trace/ftrace.c uses synchronize_rcu_tasks(). > So yes, currently one user. > And the kpatch folks want to use it too. -- Steve