lkml.org 
[lkml]   [2010]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Question about synchronize_sched_expedited()
    Hello, Paul.

    On 10/25/2010 09:41 PM, Paul E. McKenney wrote:
    >> I think your concern is valid and this can happen w/o preemption given
    >> enough cpus and perfect timing. Was the original code free from this
    >> problem?
    >
    > I believe so -- there was a mutex guarding the whole operation, including
    > the increment.

    I see.

    >> IMHO the counter based mechanism is a bit too difficult to ponder and
    >> verify. Can we do more conventional double queueing (ie. flipping
    >> pending and executing queues so that multiple sync calls can get
    >> coalesced while another one is in progress)? That's what the code is
    >> trying to achieve anyway, right?
    >
    > Hmmm... But it would be necessary to flip the queues somewhere, and
    > wouldn't determining where that somewhere was involve the same analysis
    > and complexity as determining where to increment the counter?

    I was thinking something like the following.

    lock;
    if (list_empty(running))
    add myself to running
    unlock;
    else
    remember list_empty(pending)
    append myself to pending queue;
    unlock and sleep;
    if (pending wasn't empty)
    return;

    do it;

    lock;
    wake up all on running and clear it;
    list_splice_init(pending, running);
    wake up the first of running;
    unlock;

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2010-10-26 11:29    [W:0.024 / U:119.400 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site