lkml.org 
[lkml]   [2011]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL rcu/next] fixes and breakup of memory-barrier-decrease patch

    * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

    > On Sat, May 21, 2011 at 04:28:44PM +0200, Ingo Molnar wrote:
    > >
    > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
    > >
    > > > Hello, Ingo,
    > > >
    > > > This pull requests covers some RCU bug fixes and one patch rework.
    > > >
    > > > The first group breaks up the infamous now-reverted (but ultimately
    > > > vindicated) "Decrease memory-barrier usage based on semi-formal proof"
    > > > commit into five commits. These five commits immediately follow the
    > > > revert, and the diff across all six of these commits is empty, so that
    > > > the effect of the five commits is to revert the revert.
    > >
    > > But ... the regression that was observed with that commit needs to be fixed
    > > first, or not? In what way was the barrier commit vindicated?
    >
    > From what I can see, the hang was fixed by Frederic's patch at
    > https://lkml.org/lkml/2011/5/19/753. I was interpreting that as vindication,
    > perhaps ill-advisedly.

    I mean, without Frederic's patch we are getting very long hangs due to the
    barrier patch, right?

    Even if the barrier patch is not to blame - somehow it still managed to produce
    these hangs - and we do not understand it yet.

    > Yinghai said that he was still seeing a delay, adn that he was seeing it even
    > with the "Decrease memory-barrier usage based on semi-formal proof" reverted:
    > https://lkml.org/lkml/2011/5/20/427. This hang seems to happen when he uses
    > gcc 4.5.0, but not when using gcc 4.5.1, assuming I understood his sequence
    > of emails. So I was interpreting that as meaning that the delay was unlikely
    > to be caused by that commit, probably by one of the later commits.
    >
    > I clearly need to figure out what is causing this delay. I asked Yinghai to
    > apply c7a378603 (Remove waitqueue usage for cpu, node, and boost kthreads)
    > from Peter Zijlstra because the long delays that Yinghai is seeing (93
    > seconds for memory_dev_init() rather than 3 or 4 seconds) might be due to my
    > less-efficient method of awakening the RCU kthreads, so that Peter's
    > approache might help.
    >
    > If that doesn't speed things up for Yinghai, then I will work out some
    > tracing to help localize the slowdown that he is seeing.
    >
    > Of course, if you would rather that I get to the bottom of this before
    > pulling, fair enough!

    We should fix the delay regression i suspect - do we have to revert more stuff
    perhaps?

    Would it be possible to figure out what caused that other delay for Yinghai?

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2011-05-21 21:17    [W:0.028 / U:60.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site