From owner-freebsd-arch@FreeBSD.ORG Thu Oct 1 14:02:18 2009 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 EDD051065676 for ; Thu, 1 Oct 2009 14:02:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id AB58F8FC0C for ; Thu, 1 Oct 2009 14:02:17 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5B6A946B03; Thu, 1 Oct 2009 10:02:17 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9CC5B8A01F; Thu, 1 Oct 2009 10:02:16 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Thu, 1 Oct 2009 09:53:33 -0400 User-Agent: KMail/1.9.7 References: <200909301732.20589.jhb@freebsd.org> <4AC4A567.7050204@icyb.net.ua> In-Reply-To: <4AC4A567.7050204@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910010953.33838.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 01 Oct 2009 10:02:16 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: arch@freebsd.org Subject: Re: Interrupt Descriptions 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: Thu, 01 Oct 2009 14:02:18 -0000 On Thursday 01 October 2009 8:49:43 am Andriy Gapon wrote: > on 01/10/2009 00:32 John Baldwin said the following: > > A few folks have asked recently for the ability to add descriptive strings to > > registered interrupt handlers. This is especially true since the advent of > > MSI with multiple interrupts per device. I hacked up a prototype today that > > adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * > > cookie returned by bus_setup_intr() and var args description and appends that > > to the interrupt name in the thread and vmstat -i info. The current patch > > only has the MI bits and the MD bits for amd64 as well as a sample change to > > the igb(4) driver. > > > > The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. > > > > An example from this patch is: > > > >> vmstat -i > > interrupt total rate > > irq1: atkbd0 8 0 > > irq4: uart0 751 5 > > irq6: fdc0 6 0 > > irq14: ata0 36 0 > > irq20: uhci0 20 0 > > irq23: uhci3 ehci0 2 0 > > irq28: mpt0 1661 11 > > irq256: igb0:tx 0 880 6 > > irq257: igb0:rx 0 1098 7 > > irq258: igb0:link 3 0 > > irq259: igb1:tx 0 1 0 > > irq260: igb1:rx 0 134 0 > > irq261: igb1:link 3 0 > > > > Example above doesn't demonstrate what happens when there are shared interrupts. > Would it still look nice (with sufficiently long descriptions)? Currently MSI interrupts generally aren't shared. If they are shared what happens is that the 'name:descr' bit is treated as the full name of the device and the normal "+" or "*" truncation stuff kicks in so you would maybe have: irq280: igb0:tx 0 igb0:tx 1 except that doesn't fit in MAXCOMLEN so you would have: irq280: igb0:tx 0+ For the ithread name we are stuck with MAXCOMLEN. I would like to overhaul the intrcnt stuff to possibly allow for longer names and be mostly MI (having all the longs shared across cache lines that might be shared by multiple CPUs isn't ideal either at this point). I am considering having either an array or list of intrcnt structures with a name and a count with a sysctl that exports an array for vmstat to use (the kvm bits could always rebuild the list using the same logic as the sysctl handler for crash dumps). The current design is very limiting and forces the weird space padding to make renaming intrcnt descriptions manageable when adding/removing interrupt handlers. -- John Baldwin