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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
