svn commit: r273966 - in head: share/man/man9 sys/kern sys/sys

[Attilio Rao]

On Sun, Nov 2, 2014 at 6:53 PM, Attilio Rao <attilio at freebsd.org> wrote:
> On Sun, Nov 2, 2014 at 6:49 PM, Konstantin Belousov <kostikbel at gmail.com> wrote:
>> On Sun, Nov 02, 2014 at 06:07:20PM +0100, Attilio Rao wrote:
>>> On Sun, Nov 2, 2014 at 5:59 PM, Konstantin Belousov <kostikbel at gmail.com> wrote:
>>> > It is easy and cheap to record the set of the owned lockmgr locks for
>>> > current thread. I do not believe that we have a situation where more
>>> > than 3 locks are held in one time. To give it some slack, we can record
>>> > 8 locks shared-owned and do the check for recursion in LK_CAN_SHARE().
>>> > If the thread-locks table overflows, we could either panic() or fall
>>> > back to indiscriminative deadlock avoidance (i.e. relying on the sole
>>> > td_lk_slocks value).
>>>
>>> I don't think it is going to be cheap (and certainly it is not viable
>>> for things like sx locks and rwlocks).
>> sx and rw do not implement exclusive starvation avoidance.
>
> rw do.
> It is believed for sx it should not be too helpful, on FreeBSD I've
> never seen an sx that is particulary congested.
> It can be added, however and the algorithm they would use is the same than rw.
>
>>> Checking for the owner chain anytime you acquire the lock is certainly
>>> not I would call cheap.
>>
>> I did not proposed to verify owner chain.  I said that it is easy to
>> record the locks owned by current thread, only for current thread
>> consumption.  Below is the prototype.
>
> I think it is too expensive, think that this must happen for every shared lock.
> I know we may not be using too many shared locks on lockmgr right now,
> but it is not a good reason to make  shared lock bloated and more
> expensive on lockmgr.

And to be honest, I find already wrong the fact that we don't have a
faster path for lockmgr() (ie. inlined atomics).
I think this sloppiness (at least on my side) cames on the fact that
locking overhead is not a major factor for the performance of current
lockmgr users.
That doesn't mean, however, that we should have a slower primitive.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein