[lkml]   [2012]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RFC tip/core/rcu 4/6] rcu: Clarify help text for RCU_BOOST_PRIO
    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.

     \ /
      Last update: 2012-04-26 14:51    [W:0.022 / U:5.744 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site