From owner-freebsd-arch@FreeBSD.ORG Thu Oct 1 17:54:19 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 DE11B106566B; Thu, 1 Oct 2009 17:54:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B8828FC15; Thu, 1 Oct 2009 17:54:19 +0000 (UTC) Received: from c122-107-125-150.carlnfd1.nsw.optusnet.com.au (c122-107-125-150.carlnfd1.nsw.optusnet.com.au [122.107.125.150]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n91HsF7u021930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Oct 2009 03:54:16 +1000 Date: Fri, 2 Oct 2009 03:54:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <200910010953.33838.jhb@freebsd.org> Message-ID: <20091002031720.J21519@delplex.bde.org> References: <200909301732.20589.jhb@freebsd.org> <4AC4A567.7050204@icyb.net.ua> <200910010953.33838.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, Andriy Gapon 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 17:54:19 -0000 On Thu, 1 Oct 2009, John Baldwin wrote: > 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. The design has few limits. My old implementation had no limits on name lengths. It just had a limit on the combined length, due to it allocating the string space statically. String spaces without padding require about 10 extra lines to create and zero extra lines to use (since the users already expect a string space so they already have the extra lines to walk over it). Changing the descriptions, including rebuilding the whole string space whenever an interrupt handler is added/removed/renamed shouldn't be a problem since this is a rare event. Just lock out the sysctl and other accesses to the string space while changing/reallocating the string space. Counters are harder -- you can't move them without locking out interrupt handlers that increment them. You could also delay rebuilding until the sysctl (wouldn't be so easy for kvm). The sysctl would take longer, but perhaps no longer than now since the data size should be much smaller -- instead of 100's of padded strings there should be only a few unpadded ones (the strings on ref8-i386 now consists of 49 "stray irqN" (padded), 42 unused "irqN:" (padded), one "???" (padded; unused I think -- this "???" is for when the table fills up and/or when an unexpected irq occurs, but the table now covers everything and has zillions of stray slots for unexpected ireq), and 15 lines for interrupts actually attached (8 lapic timer, 2 moderately used, 1 rarely used, 3 never used). systat wouldn't like the tables' sizes or string contents changing underneath it, but in the rare event that this happens it couldn't do worse than crash, and it could detect the change using a new generation count. vmstat wouldn't have any problems since it only reads the tables once (minor race between the independent sysctls). The kvm interface doesn't support dynamic table allocation. You would probably have to change it eventually to support per-CPU counters if you actually want to keep supporting interrupt stats in dead kernels. Bruce