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

[Attilio Rao]

On Sun, Nov 2, 2014 at 8:10 PM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Sun, Nov 02, 2014 at 06:53:44PM +0100, Attilio Rao wrote:
>> > 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.
>
> It can be significantly simplified, if the array of lock pointers is
> kept dense.  Then the only non-trivial operation is unlock out of order,
> when the array have to be compacted.
>
> The code adds one write and n reads on shared lock, where n is the
> number of shared-locked locks already owned by thread. Typical n is 0
> or 1. On unlock, if done in order, the code adds one read; unordered
> unlock shuffles array elements. Again, for typical lock nesting of 2,
> this means one read and one write, and even this is rare. All reads and
> writes are for thread-local memory.
>
> I am not going to spend any more time on this if people do not consider
> the lock tracking worth it.  Otherwise, I will benchmark the patch.

I think that your initial patch (what is in head now) is a better approach.
I would just make it a lockinit() flag to make it less alien to the KPI.

Attilio


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