On Mon, 8 Sep 2008 16:20:52 +0200 Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > On Mon, Sep 08, 2008 at 10:02:30AM -0400, Chris Mason wrote: > > On Mon, 2008-09-08 at 15:54 +0200, Andi Kleen wrote: > > > > The idea is to try to spin for a bit to avoid scheduling away, which is > > > > especially important for the high levels. Most holders of the mutex > > > > let it go very quickly. > > > > > > Ok but that surely should be implemented in the general mutex code then > > > or at least in a standard adaptive mutex wrapper? > > > > That depends, am I the only one crazy enough to think its a good idea? > > Adaptive mutexes are classic, a lot of other OS have it. The problem is that they are a nuisance. It is impossible to choose the right trade off between spin an no-spin, also they optimize for a case that doesn't occur often enough to be justified. People seem to repeatedly come up with adaptive mutex based on intuitive hunch, and never do much analysis before or afterwards. You need some facts to come up with a useful model: % of time lock is contended average lock hold time overhead of entry-exit for lock primitive (spin time) overhead of the adaptive version either pure spin or pure mutex Also, adaptive locks have even worse unfairness than spin locks under contention. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
