svn commit: r194012 - in head: . sys/netgraph sys/sys

Robert Watson rwatson at
Fri Jun 12 09:44:14 UTC 2009

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 

Robert N M Watson
Computer Laboratory
University of Cambridge

More information about the svn-src-all mailing list