From owner-cvs-src@FreeBSD.ORG Sun Jun 18 13:46:41 2006 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AF6516A474; Sun, 18 Jun 2006 13:46:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BEC643D45; Sun, 18 Jun 2006 13:46:40 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id BBE2846BFA; Sun, 18 Jun 2006 09:46:39 -0400 (EDT) Date: Sun, 18 Jun 2006 14:46:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <449552C9.7060203@freebsd.org> Message-ID: <20060618143447.S10901@fledge.watson.org> References: <200606171757.k5HHvahf087725@repoman.freebsd.org> <4494FDF5.1070901@errno.com> <20060618080019.B60374@maildrop.int.zabbadoz.net> <449552C9.7060203@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bjoern A. Zeeb" , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Sam Leffler Subject: Re: cvs commit: src/sys/netinet tcp_var.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2006 13:46:41 -0000 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