[lkml]   [2010]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.

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

    do it;

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



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