Re: Use case for TASKS_RCU

From	Steven Rostedt <rostedt@goodmis.org>
Newsgroups	linux.kernel
Subject	Re: Use case for TASKS_RCU
Date	2017-05-19 16:10 +0200
Message-ID	<tIQLo-3eE-15@gated-at.bofh.it> (permalink)
References	<tHsUN-3dA-11@gated-at.bofh.it> <tHE9A-22D-21@gated-at.bofh.it> <tHJLZ-5yL-35@gated-at.bofh.it> <tIJAd-6Ek-11@gated-at.bofh.it> <tIQim-2MD-21@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Fri, 19 May 2017 06:35:50 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> 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

Thread

Use case for TASKS_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-15 20:30 +0200
  Re: Use case for TASKS_RCU Steven Rostedt <rostedt@goodmis.org> - 2017-05-15 20:50 +0200
    Re: Use case for TASKS_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-15 22:20 +0200
  Re: Use case for TASKS_RCU Ingo Molnar <mingo@kernel.org> - 2017-05-16 08:30 +0200
    Re: Use case for TASKS_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-16 14:30 +0200
      Re: Use case for TASKS_RCU Steven Rostedt <rostedt@goodmis.org> - 2017-05-16 15:10 +0200
        Re: Use case for TASKS_RCU Masami Hiramatsu <mhiramat@kernel.org> - 2017-05-24 11:40 +0200
      Re: Use case for TASKS_RCU Ingo Molnar <mingo@kernel.org> - 2017-05-19 08:30 +0200
        Re: Use case for TASKS_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-19 15:40 +0200
          Re: Use case for TASKS_RCU Steven Rostedt <rostedt@goodmis.org> - 2017-05-19 16:10 +0200
            Re: Use case for TASKS_RCU Steven Rostedt <rostedt@goodmis.org> - 2017-05-19 16:30 +0200
              Re: Use case for TASKS_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-19 21:10 +0200
                Re: Use case for TASKS_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-23 02:10 +0200
                Re: Use case for TASKS_RCU Steven Rostedt <rostedt@goodmis.org> - 2017-05-23 07:30 +0200
                Re: Use case for TASKS_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-23 17:40 +0200
                Re: Use case for TASKS_RCU Steven Rostedt <rostedt@goodmis.org> - 2017-05-23 21:50 +0200
                Re: Use case for TASKS_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-23 22:10 +0200
                Re: Use case for TASKS_RCU Steven Rostedt <rostedt@goodmis.org> - 2017-05-23 22:50 +0200
                Re: Use case for TASKS_RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-23 23:20 +0200

csiph-web