Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Apr 2006 03:54:07 -0400
From:      "Surer Dink" <surerlistmail@gmail.com>
To:        "Kris Kennaway" <kris@obsecurity.org>, smp@freebsd.org, current@freebsd.org
Subject:   Re: Anomalous performance increase from mutex profiling
Message-ID:  <b00a10c30604170054r57d13768u4aeb79e91c436d51@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
On Mon, 17 Apr 2006, Kris Kennaway wrote:

> On Mon, Apr 17, 2006 at 01:14:40AM -0400, Kris Kennaway wrote:
>
>> * Our best guess is that mutex profiling is doing something that
>> reduces contention on this very heavily contended mutex (unp), but I'd
>> like to know what is happening precisely so I can maybe make use of
>> it.
>>
>> Can anyone think of what may be happening that I've missed?
>
> I think it is just doing effectively the same thing as my exponential
> spin backoff patch, namely introducing delays with the effect of
> reducing common memory accesses.  When I turn the maximum spin backoff
> limit *way* up (from 1600 to 51200) I get performance that slightly
> exceeds what I see from mutex profiling alone (adding mutex profiling
> again on top of this gives a small further increase, but only a few %
> and so probably achievable by further increasing the backoff limit).
>
> A limit of 51200 is not an appropriate default since it penalizes the
> common case of light to moderate contention.  The point is that here
> basically all 12 CPUs are spinning on a single lock
> (kern/uipc_usrreq.c:308), so it's massively over-contended and all we
> can do is mitigate the effects of this.
>
> On this system, the maximum supersmack performance (3700 queries/sec)
> comes when there are only 6 clients, so (as jasone eloquently put it)
> with 10 clients the difference between 2300 queries/sec (with absurdly
> high backoff limits or mutex profiling) and 1450/sec (with reasonable
> backoff limits) is the difference between "slow" and "ass slow".

Please excuse if this is a stupid question - but might using MCS or
QOLB locks in this situation be useful?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b00a10c30604170054r57d13768u4aeb79e91c436d51>