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

[Konstantin Belousov]

On Sun, Nov 02, 2014 at 10:17:26PM +0100, Attilio Rao wrote:
> 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.
> 

Ok.

Can you explain what would the proposed lockinit() flag do ? What should
it change comparing with the current code ?