witness performance improvements

[Jeff Roberson]

On Sat, 19 Jul 2008, Attilio Rao wrote:

> 2008/7/19, Jeff Roberson <jroberson at jroberson.net>:
>> Hello,
>>
>>  I have a patch that improves witness performance available at:
>>
>>  http://people.freebsd.org/~jeff/witness.diff
>>
>>  This improvement comes at the cost of some significant space overhead.  It
>> changes the witness graph from a linked tree to a matrix based approach.
>> Relationships can be quickly resolved with a table lookup.  The table size
>> is WITNESS_COUNT^2, or 1MB with the current count of 1024.
>>
>>  This patch also makes struct witness objects persistent even after the last
>> lock using this name has been removed.  This is helpful for short lived
>> objects which may be created frequently.
>>
>>  To reduce lock contention on SMP witness_checkorder() now runs without the
>> w_mtx when there are no lock violations.  I also cache a lock_list_entry in
>> each thread as allocating these requires the w_mtx.  The entry is disposed
>> of at thread_exit().
>>
>>  There is also a new sysctl that produces dot output which graphs lock order
>> relationships with the graphviz program.
>
> As I alredy said, I don't like this.
> I mostly prefer the current approach (comma separated stuff) that one
> can shape as its need.
> If you also think there are some informations the current sysctl
> doesn't export and it should we could fix it, but IMHO we should axe
> this part of the patch (I have still to look at this patch, but I
> remind in the Isilon's version it was a good amount of structures and
> modifies just to handle that part).

Can you estimate how much effort it would take to port your previous graph 
solution to the current witness code?


>
>>  Most of this work was done by Ilya Maykov while he was at Isilon systems.
>> The locking work and some cleanup/porting/refinement was done by me on
>> behalf of Nokia.
>>
>>  The performance improvement can be significant.  It is only on the order of
>> 10-20% for buildkernel but on a packet forwarding test at nokia it sped
>> things up by 5x putting a witness enabled kernel within about 50% of the
>> performance of a kernel without.  I believe buildworld isn't helped as much
>> because forking and exiting a lot would then contend on the witness lock.
>>
>>  I'm mostly interested in hearing what people have to say about the space
>> bloat.  I believe it is in a commit ready state.
>
> This should not be a big problem, it is a debugging kernel after all
> if it has WITNESS.
>
> I hope I will have more time for a detailed revision in the day.

I would appreciate that.

Thanks,
Jeff

>
> Thanks,
> Attilio
>
>
> -- 
> Peace can only be achieved by understanding - A. Einstein
>