Date: Fri, 12 Jun 2009 10:44:12 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, svn-src-all@freebsd.org, Marko Zec <zec@freebsd.org>, Julian Elischer <julian@elischer.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r194012 - in head: . sys/netgraph sys/sys Message-ID: <alpine.BSF.2.00.0906121041310.12555@fledge.watson.org> In-Reply-To: <20090611202757.7cb0dad5@kan.dnsalias.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0906121041310.12555>