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

[Attilio Rao]

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.

Attilio


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