cvs commit: src/sys/netinet tcp_var.h
andre at freebsd.org
Sun Jun 18 13:19:06 UTC 2006
Bjoern A. Zeeb wrote:
> On Sun, 18 Jun 2006, Sam Leffler wrote:
>> Andre Oppermann wrote:
>>> andre 2006-06-17 17:57:36 UTC
>>> FreeBSD src repository
>>> Modified files:
>>> sys/netinet tcp_var.h
>>> Rearrange fields in struct syncache and syncache_head to make them
>>> cache line friendly.
>> Got any benchmarks to back this up? Or perhaps it was just the smiley
>> face your cache lines gave you :)
The entry chains are traversed quite often and the first thing looked
at is in_conninfo and then sc_rxttime and sc_rxmits. So it makes a
lot of sense to have them close together on the same cache line aligned
to the beginning of the struct and to the native alignment of the
architecture. I did not benchmark it but it is simple reasoning.
> That indeed is a good question. From looking at the patch I can see
> a new lock introduced while there are other people working on reducing
> locking and locking overhead in our network stack trying different
> I hadn't seen a patch or any numbers in this months arch@ or net@
> archives (maybe I missed it?).
> At the current phase of network stack hacking we should take the
> time to get these kind of changes benchmarked under various
> loads from different people or at least give them the chance to do
> so so nobody can complain afterwards. At least if one wants to
> claim performance improvements.
Robert Watson and Paul Saab ran the syncache locking changes in their
testbeds and found 0.7% and 0% regression. The syncache locking will
have its benefits when we deserialize the packet input path. Also the
global tcpinfo lock is held for only a very short amount of time instead
of the whole time.
More information about the cvs-src