Re: [PATCH RFC tip/core/rcu 4/6] rcu: Clarify help text forRCU_BOOST_PRIO

From: Peter Zijlstra
Date: Thu Apr 26 2012 - 08:47:11 EST


On Mon, 2012-04-23 at 09:42 -0700, Paul E. McKenney wrote:
> + This option specifies the real-time priority to which long-term
> + preempted RCU readers are to be boosted. If you are working
> + with a real-time application that has one or more CPU-bound
> + threads running at a real-time priority level,

Then your application is broken ;-) the kernel is known to mis-behave
under these circumstances since it doesn't get to run house-keeping
tasks. RCU is just one of these and elevating it doesn't make it work.

> you should set
> + RCU_BOOST_PRIO to a priority higher then the highest-priority
> + real-time CPU-bound thread. The default RCU_BOOST_PRIO value
> + of 1 is appropriate in the common case, which is real-time
> + applications that do not have any CPU-bound threads.

Alternatively, 1 is the worst possible choice forcing people to consider
the issue.

> + Some real-time applications might not have a single real-time
> + thread that saturates a given CPU, but instead might have
> + multiple real-time threads that, taken together, fully utilize
> + that CPU. In this case, you should set RCU_BOOST_PRIO to
> + a priority higher than the lowest-priority thread that is
> + conspiring to prevent the CPU from running any non-real-time
> + tasks. For example, if one thread at priority 10 and another
> + thread at priority 5 are between themselves fully consuming
> + the CPU time on a given CPU, then RCU_BOOST_PRIO should be
> + set to priority 6 or higher.

I'd call this misleading, who's to say that preempting the 5 would yield
enough time to complete the RCU work?

This all gets us back to the fun question of RCU delayed bandwidth
budgeting.. ideally every 'task' that does call_rcu() should donate some
of its budget towards the thread running the callback.

Anyway, I'd argue both the old and new description are bonkers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/