Date: Sun, 18 Jun 2006 15:19:05 +0200 From: Andre Oppermann <andre@freebsd.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: Sam Leffler <sam@errno.com>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_var.h Message-ID: <449552C9.7060203@freebsd.org> In-Reply-To: <20060618080019.B60374@maildrop.int.zabbadoz.net> References: <200606171757.k5HHvahf087725@repoman.freebsd.org> <4494FDF5.1070901@errno.com> <20060618080019.B60374@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >>> Log: >>> Rearrange fields in struct syncache and syncache_head to make them >>> more >>> 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 > strategies. > > 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. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?449552C9.7060203>