[lkml]   [2012]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH RFC] rcu: Make __rcu_read_lock() inlinable
    On Mon, Mar 26, 2012 at 08:47:10PM +0200, Peter Zijlstra wrote:
    > On Mon, 2012-03-26 at 11:32 -0700, Paul E. McKenney wrote:
    > >
    > > I could inline them into sched.h, if you are agreeable.
    > Sure, or put it in kernel/sched/core.c.

    That was my first thought, but there is a use of switch_to() in

    > > I am a bit concerned about putting them both together because I am betting
    > > that at least some of the architectures having tracing in switch_to(),
    > > which I currently do not handle well.
    > I would hope not.. there's a generic trace_sched_switch() and
    > switch_to() is supposed to be black magic. I'd be fine breaking that as
    > long as we can detect it.

    Hmmm... I am not yet sure whether it is easier to make RCU use legal
    in switch_to() or to detect it. I am inclined to take whatever course
    is easiest, which is likely to make it legal. :-/

    > > At the moment, the ways I can
    > > think of to handle it well require saving before the switch and restoring
    > > afterwards. Otherwise, I can end up with the ->rcu_read_unlock_special
    > > flags getting associated with the wrong RCU read-side critical section,
    > > as happened last year.
    > >
    > > Preemption is disabled at this point, correct?
    > Yeah, and soon we'll have interrupts disabled as well (on all archs,
    > currently only ARM has interrupts enabled at this point).

    Good to know!

    > > Hmmm... One way that I could reduce the overhead that preemptible RCU
    > > imposes on the scheduler would be to move the task_struct queuing from
    > > its current point upon entry to the scheduler to just before switch_to().
    > > (The _bh and _sched quiescent states still need to remain at scheduler
    > > entry.) That would mean that RCU would not queue tasks that entered
    > > the scheduler, but did not actually do a context switch.
    > That would make sense anyhow, right? No point in queueing a task if you
    > didn't actually switch away from it.

    Also it would simplify the save and restore operation, I believe.

    > > Would that be helpful?
    > For now that's preemptible rcu only, and as such a somewhat niche
    > feature (iirc its not enabled in the big distros) so I don't think it
    > matters too much. But yeah, would be nice.

    OK, let me see what works best.

    Thanx, Paul

     \ /
      Last update: 2012-03-27 07:17    [W:0.022 / U:6.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site