linux-kernel - adaptive mutexes, was Re: btrfs_tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20080908171648.GA19117@infradead.org>
Date:	Mon, 8 Sep 2008 13:16:48 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Chris Mason <chris.mason@...cle.com>,
	linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: adaptive mutexes, was Re: btrfs_tree_lock & trylock

On Mon, Sep 08, 2008 at 08:07:51AM -0700, Stephen Hemminger wrote:
> 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.

Well, the traditional wisdom in kernel land is that you want a spinlock
if the contention phases are short.  But we grow more an more places
where we might do sleep under the lock.  One optimization would be
to spin, but only if the mutex holder is not sleeping.  Or we make the
spinning a completely different API, mutex_lock_adaptive()

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