Date: Sat, 19 Jul 2008 14:25:57 +0200 From: "Attilio Rao" <attilio@freebsd.org> To: "Jeff Roberson" <jroberson@jroberson.net> Cc: arch@freebsd.org, ivmaykov@gmail.com Subject: Re: witness performance improvements Message-ID: <3bbf2fe10807190525y65facf80uad2a974619198186@mail.gmail.com> In-Reply-To: <20080718163231.B954@desktop> References: <20080718163231.B954@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
2008/7/19, Jeff Roberson <jroberson@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). > 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. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10807190525y65facf80uad2a974619198186>