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.058 / U:0.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site