Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Tue, 13 Jan 2009, Ingo Molnar wrote:
> >
> > And v8 is rock solid in all my testing - and i'll give v10 a similar 
> > workout as well.
> 
> The differences between v8 and v10 are very fundamental, since v8 does 
> the spinning inside the spinlock'ed loop (the spinning itself is not 
> inside the spinlock, but all the "real action" is).  So v8 not showing 
> problems doesn't really say much about v10 - totally different 
> algorithms that share only some of the support code.
> 
> So even if many lines look the same, those code-lines aren't the really 
> interesting ones. The only really interesting once is really the 
> atomic_cmpxchg (outside spinlock) vs atomic_xchg (inside spinlock), and 
> those are almost diametrically opposite.

yeah. What i thought they would be useful for are testing and experiments 
like this:

" what if you switch the spinning to more fair by typing this in your 
  current tree:

     git revert c10b491
"

... but that's a pretty narrow purpose.

> > Would you prefer a single commit or is this kind of delta development 
> > history useful, with all the variants (at least the later, more 
> > promising ones) included?
> 
> I'm not sure it makes sense to show the history here, especially as 
> there really were two different approaches, and while they share many 
> issues, they sure aren't equivalent nor are we really talking about any 
> evolution of the patch except in the sense of one being the kick-starter 
> for the alternative approach.
> 
> What _can_ make sense is to commit some of the infrastructure helper 
> code separately, ie the lock ownership and preemption changes, since 
> those really are independent of the spinning code, and at least the 
> preemption thing is interesting and relevant even without it.

ok, we'll improve the splitup.

	Ingo
--
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/