From owner-svn-src-head@FreeBSD.ORG Fri Jun 12 09:44:13 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9548A106564A; Fri, 12 Jun 2009 09:44:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 680EF8FC19; Fri, 12 Jun 2009 09:44:13 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id F1EF146B2C; Fri, 12 Jun 2009 05:44:12 -0400 (EDT) Date: Fri, 12 Jun 2009 10:44:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Kabaev In-Reply-To: <20090611202757.7cb0dad5@kan.dnsalias.net> Message-ID: References: <200906111650.n5BGonnn053446@svn.freebsd.org> <20090611190140.GE2642@garage.freebsd.pl> <200906112123.02105.zec@freebsd.org> <4A3168A0.2090308@elischer.org> <20090611202757.7cb0dad5@kan.dnsalias.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, Pawel Jakub Dawidek , svn-src-all@freebsd.org, Marko Zec , Julian Elischer , svn-src-head@freebsd.org Subject: Re: svn commit: r194012 - in head: . sys/netgraph sys/sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 09:44:14 -0000 On Thu, 11 Jun 2009, Alexander Kabaev wrote: >>>> Are you sure Marko that you can't use sys/sys/osd.h instead of adding yet >>>> another field to the thread structure? Netgraph is optional component and >>>> optional components could take advantage of allocating stuff they need >>>> dynamically. The OSD (Object-Specific Data) KPI is designed for use by >>>> optional components - you can add your data to a thread, you can get it >>>> when you want and OSD will call your callback when thread dies, so you >>>> can clean up. >>>> >>>> Maybe you can't, but it's worth checking. >>> >>> Hmm how much locking overhead do osd_set() / osd_get() methods introduce? >>> We have to bump the refcount on each entry to netgraph, and then check it >>> potentially on each hop to next ng node, and finally drop the refcount >>> when done with the function call into netgraph. Accessing td_ng_outbound >>> directly via curthread is as cheap as it gets performancewise as it >>> requires no locking whatsoever... >> >> I would add that I suspect that we may end up using it in other places as >> well outside of netgraph. > > When that happens then per-thread field can be revisited again. Blowing the > side of major kernel structure for the sake of subsystem is unused by 90%+ > percent of users is little too drastic IMHO. > > I do second Pawel's opinion that you should look at osd for the time being. > After all it was invented for just this reason. I guess I come down on the other side of this one -- the cost of an int in struct thread is minimal compared to many of the other overheads, and means that the cost of managing the input/output cycle protection is minimal for something that happens to all packets processed by a moderate number of useful netgraph nodes. Last I checked there was plenty of other garbage we could collect in struct thread/proc if we are worried about its size, and it was also organized fairly badly from an alignment perspective so there was lots of entirely wasted space in padding (perhaps someone has fixed this since I last looked?). Robert N M Watson Computer Laboratory University of Cambridge