Re: prepare_wait / finish_wait question

[Manfred Spraul]

Andrew Morton wrote:

> Manfred Spraul <manfred@xxxxxxxxxxxxxxxx> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/