Date: Sun, 18 Jun 2006 14:46:39 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Sam Leffler <sam@errno.com> Subject: Re: cvs commit: src/sys/netinet tcp_var.h Message-ID: <20060618143447.S10901@fledge.watson.org> In-Reply-To: <449552C9.7060203@freebsd.org> References: <200606171757.k5HHvahf087725@repoman.freebsd.org> <4494FDF5.1070901@errno.com> <20060618080019.B60374@maildrop.int.zabbadoz.net> <449552C9.7060203@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Jun 2006, Andre Oppermann wrote: >> 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. While the technical argument for the patch is good, I think the general tone of caution expressed by Sam, Bjoern, et al, is also important: over the past ten years, a lot of changes have been made that are considered "long term architectural investments" -- that is, changes that pessimize in the short term and are intended to optimize in the long term. The caution is appropriate because in many cases, the long term optimizations have yet to materialize, leaving us with lots of short term pessimizations. For massive architectural changes, such as fundamental changes in synchronization model, this is sometimes necessary, but for smaller point changes, maintaining and testing out of the tree is both feasible and often desirablej There's a lot to be said for keeping significant works in progress in working branches in Perforce until it can be demonstrated that the eventual wins can in fact be realized by the proposed approach. Keeping the WIP's in Perforce doesn't necessarily mean reduced review and exposure -- it makes it easier to point test specific changes in test environments, and plug-and-play changes in test combinations without committing to the changes by merging them to CVS, which is valuable. I know that Kris and I (and no doubt others) find Perforce a valuable tool for sharing working branches, since versioned patchsets are no longer required, which makes testing and review much harder. Working in Perforce also gives more access to incremental review -- something our SoC students are learning rapidly, as they start getting feedback on their works in progress from people they've never heard of! :-) 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?20060618143447.S10901>