From owner-freebsd-arch@FreeBSD.ORG Sat Jul 19 12:55:09 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2B89106566B for ; Sat, 19 Jul 2008 12:55:09 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6F68FC15 for ; Sat, 19 Jul 2008 12:55:09 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so424117fgb.35 for ; Sat, 19 Jul 2008 05:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=fwGsCg5xZShNq7OUS6rFwy9bg0EiGcmRe8KjYlBAums=; b=ZOxYx3ybX+Zdx57MT61Zdi82h0nW2S1MaWE2yvcueD1nRfArh6BxJTgEoMQF+3Kz3C 7gZ9E+Bi6UhQzrVyL6YnSQJcj1kC0DoLaB50SEgbe3Rtr6VKjA1HpPV8cf9S+UhPl5Xc Z91GPeSUsncaiI5JOBi3HE+mG2LIb0ZQ911Rs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=YDb0a50ATJNeE943p/V+qhhR6tzqz4ya3LylEX5gkS9WFbOo/oBdErIV2vs0Ihcofw fNi+OQX3I4AOfupceHDlQ9KtWNsEeABxGRLNlFYxSxNyQY59Eu+eaFgaoixTXYzjfKYm l/fmC801mzcZUpWdvFMVW5BjU42DIsUgvbWFw= Received: by 10.86.79.19 with SMTP id c19mr1983189fgb.5.1216470357910; Sat, 19 Jul 2008 05:25:57 -0700 (PDT) Received: by 10.86.2.18 with HTTP; Sat, 19 Jul 2008 05:25:57 -0700 (PDT) Message-ID: <3bbf2fe10807190525y65facf80uad2a974619198186@mail.gmail.com> Date: Sat, 19 Jul 2008 14:25:57 +0200 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "Jeff Roberson" In-Reply-To: <20080718163231.B954@desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080718163231.B954@desktop> X-Google-Sender-Auth: beeac40afbaf3620 Cc: arch@freebsd.org, ivmaykov@gmail.com Subject: Re: witness performance improvements X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2008 12:55:09 -0000 2008/7/19, Jeff Roberson : > 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