Re: prepare_wait / finish_wait question

[Manfred Spraul <manfred@colorfullife.com>]

Andrew Morton wrote:

>Manfred Spraul <manfred@colorfullife.com> wrote:
>  
>
>>Hi Ingo,
>>
>>sysv semaphores show the same problem you've fixed for wait queue with 
>>finish_wait:
>>    
>>
>
>Was me, actually.
>  
>
Ups, sorry.

>It would be neater to remove the task from the list _before_ waking it up. 
>The current code in there is careful to only remove the task if the wakeup
>attempt was successful, but I have a feeling that this is unnecessary - the
>waiting task will do the right thing.  One would need to think about that a
>bit more.
>  
>
Doesn't work: the woken up thread could be woken up by chance through a 
signal, and then the task structure could go out of scope while wake_up 
is still running - oops. Seen on s390 with sysv msg.

>>I wrote a patch for sysv sem and on a 4x Pentium 3, 99.9% of the calls 
>>hit the fast path, but I'm a bit afraid that monitor/mwait could be so 
>>fast that the fast path is not chosen.
>>    
>>
>
>Is it not the case that ia32's reschedule IPI is async?  If the
>architecture's reschedule uses a synchronous IPI then it could indeed be
>the case that the woken CPU gets there first.
>
poll_idle polls the need_resched flag, and next generation pentium 4 
cpus will poll the need_resched flag with the MONITOR/MWAIT 
instructions. We cannot rely on the async IPI.

>>I'm thinking about a two-stage algorithm - what's your opinion?
>>    
>>
>
>Instrumentation on other architectures would be interesting.
>  
>
The patch already contains the instrumentation - it only needs testing.

--
    Manfred