lkml.org 
[lkml]   [2009]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch] sched: fix set_task_cpu() and provide an unlocked runqueue variant
    From
    Date
    On Thu, 2009-11-26 at 10:35 +0100, Peter Zijlstra wrote:
    > On Thu, 2009-11-26 at 02:31 +0100, Mike Galbraith wrote:
    > > On Thu, 2009-11-26 at 02:01 +0100, Mike Galbraith wrote:
    > > > On Wed, 2009-11-25 at 19:27 +0100, Peter Zijlstra wrote:
    > >
    > > > > I've got to ask, what's that barrier for?
    > > >
    > > > It's a leftover from frustrated bug hunting.
    > >
    > > To be more specific, I put it there to ensure that min_vruntimes are
    > > stable.
    >
    > min_vruntime should only ever be poked at when holding the respective
    > rq->lock, even with a barrier a 64bit read on a 32bit machine can go all
    > funny.

    Yeah, but we're looking at an unlocked runqueue. But never mind...

    > > I figured that if try_to_wake_up() needs a barrier to look at
    > > task->state, I had better do the same for the runqueues.
    >
    > Ah, ttwu() has that barrier for another reason. The wmb in ttwu() is to
    > ensure the wakee sees the state of the waker at the time of waking.
    >
    > That is, its about ordering things like:
    >
    >
    > A B
    >
    >
    > my_cond = true;
    > wake_process(my_friend);
    >
    > while (!my_cond)
    > schedule();
    >
    >
    > So that you can actually observe my_cond being true once you wakeup
    > (schedule acts as a mb() when it actually schedules).

    (Ah! I think you actually made a wrinkle in grey-ware)

    ...ATM, I kinda wish I'd not gone off and read barriers.txt. It hasn't
    sunk in yet, but certainly has made me _paranoid as hell_ :-)

    -Mike



    \
     
     \ /
      Last update: 2009-11-26 11:19    [W:0.021 / U:0.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site