On Wed, Aug 27, 2008 at 12:41:08PM +0200, Peter Zijlstra wrote:
quoted text
> On Wed, 2008-08-27 at 12:26 +0200, Nick Piggin wrote:
> > On Wed, Aug 27, 2008 at 10:21:35AM +0200, Peter Zijlstra wrote:
> 
> > > I suppose one could then write it like:
> > > 
> > >   if (spin_is_contended(&this_rq->lock) || !spin_trylock(&busiest->lock)) {
> > >     spin_unlock(&this_rq->lock);
> > >     double_rq_lock(this_rq, busiest);
> > >   }
> > > 
> > > But, I'm not sure that's worth the effort at that point..
> > 
> > Yeah, that could work, but hmm it might cause 2 cache coherency transactions
> > anyway even in the fastpath, so it might even be slower than just unlocking
> > unconditionally and taking both locks :(
> 
> right,..
 

Although I guess we could prefetch it... But OTOH I don't know exactly
what Intel CPUs do with prefetch -- I don't think they have a prefetchw.

I would support your idea if it is faster, of course ;)


quoted text
> > > Anyway - I think all this is utterly defeated on CONFIG_PREEMPT by the
> > > spin with IRQs enabled logic in kernel/spinlock.c.
> > > 
> > > Making this an -rt only patch...
> > 
> > Hmm, and also on x86 with ticket locks we don't spin with preempt or
> > interrupts enabled any more (although we still do of course on other
> > architectures)
> 
> Aah, we don't do CONFIG_GENERIC_LOCKBREAK anymore?
 
Right. My reasoning said that if our critical sections are short enough,
*and not subject to starvation*, then we should not really need it, and
at any rate often it is just luck if it helps because in other cases
we might be taking the lock under an irq save region so it wouldn't help
there...


quoted text
> Does it make sense to make this _double_lock_balance() thing depend on
> that too?

Hmm, you might have a good point there. Greg?

BTW. I wonder about other architectures that are of interest to -rt? Like
mips or arm perhaps... Any plans to implement ticket locks on those, or
do they not tend to be used in SMP configurations on -rt yte?

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