svn commit: r194012 - in head: . sys/netgraph sys/sys
Robert Watson
rwatson at FreeBSD.org
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
looked?).
Robert N M Watson
Computer Laboratory
University of Cambridge
More information about the svn-src-head
mailing list