From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753237AbdESOE1 (ORCPT ); Fri, 19 May 2017 10:04:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:58668 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751336AbdESOEZ (ORCPT ); Fri, 19 May 2017 10:04:25 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7B45223961 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: Fri, 19 May 2017 10:04:21 -0400 From: Steven Rostedt To: "Paul E. McKenney" Cc: Ingo Molnar , linux-kernel@vger.kernel.org, Peter Zijlstra , Thomas Gleixner Subject: Re: Use case for TASKS_RCU Message-ID: <20170519100421.27298063@gandalf.local.home> In-Reply-To: <20170519133550.GD3956@linux.vnet.ibm.com> References: <20170515182354.GA25440@linux.vnet.ibm.com> <20170516062233.tyz7ze7ilmbkxtjc@gmail.com> <20170516122354.GB3956@linux.vnet.ibm.com> <20170519062331.52dhungzvcsdxdgo@gmail.com> <20170519133550.GD3956@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 Fri, 19 May 2017 06:35:50 -0700 "Paul E. McKenney" wrote: > Simpler would be better! > > However, is it really guaranteed that one SCHED_IDLE thread cannot > preempt another? If not, then the trampoline-freeing SCHED_IDLE thread > might preempt some other SCHED_IDLE thread in the middle of a trampoline. > I am not seeing anything that prevents such preemption, but it is rather > early local time, so I could easily be missing something. > > However, if SCHED_IDLE threads cannot preempt other threads, even other > SCHED_IDLE threads, then your approach sounds quite promising to me. > > Steve, Peter, thoughts? SCHED_IDLE is the swapper task. There's one on each CPU, and they don't migrate. And they only get called when there's no other task running. My worry is that if you have a busy CPU, then this will never finish, as the idle task can be preempted forever. That would cause this to never return: perf record -e ftrace:function sleep 1 That may never exit when it finishes, because the call to unregister_ftrace_function() wont return till schedule_rcu_tasks() returns. And worse yet, that is TASK_UNINTERRUPTIBLE state, where not even a ctrl-C will stop it. It could possibly also trigger a hung task warning. -- Steve