Just in case you missed the e-mails over the last few weeks, I will be starting to merge socket and pcb reference changes today. This will result in: - Hopefully brief tree breakage. I won't bring all the changes in in a single commit in order to generate a more detailed log of the changes. This means there may be several hours today when the kernel doesn't build, the tinderbox complains, etc. - Short term instability. While these changes have been through quite a bit of testing, including by Kris and Paul under high load circumstances, there are likely significant bugs remaining in them that will be exercised only under more diverse load, or with more creativity applied. - Long term improvements, as these changes should reduce lock contention on critical network locks, offer better-documented and better-implemented structural invariants in the network stack, close a number of long-standing race conditions and bugs, and provide a strong foundation for the next iteration of protocol locking improvements. You get to experience the above in the order presented. :-) I will send out a follow-up e-mail once the merges have stopped and/or slowed down, which will be later today sometime. Robert N M Watson On Wed, 29 Mar 2006, Robert Watson wrote: > > On Fri, 17 Mar 2006, Robert Watson wrote: > >> Over the next few weeks, I'll be doing a fairly serious workworking of the >> socket and protocol reference models, in order to clean up a number of >> long-standing race conditions and provide infrastructure for significant >> locking optimizations for several protocols (including TCP). This is high >> risk work, in that this part of the socket code is very complex and there >> are a great many subtleties. Part of the goal of the work is to eliminate >> some of this complexity, and make the subtle a bit more obvious (and >> documented), so I think it's all for the good in the long term. However, >> it will likely introduce significant instability in the short term, >> especially in the TCP code where there will be substantial changes in the >> memory management model. >> >> I've started merging minor parts of the patch over the last few days, but >> things will get serious around April 1 when the deadline for maintenance on >> the netatm stack expires (see arch_at_ and net_at_ posts about this), allowing me >> to bring in changes that are not known to work with netatm. As such, be >> warned that things may get a bit messy! > > As a reminder, April 1 is now three days away. On April 1, I will be > committed an extensive set of socket and netinet changes which will likely > render the network stack broken. I say this with some confidence because I > have tested the changes fairly extensively, as have a number of other > developers, and they appear to mostly work. Therefore, they will be broken > :-). I will be posting updated versions of these patches shortly, but unless > we run into show-stopper serious instability with them, rather than nits, I > will commit them (in their updated form) on April 1 shortly after the netatm > build is disabled. > > I will post another HEADS UP as the changes go into the tree, and will be > monitoring things closely to try and get any bugs that might turn up fixed as > quickly as possible. As an FYI, I will be travelling the weeks of April 6 - > April 21, but will be online frequently, and working for several days in the > Bay Area during the trip. Please report bugs relating to this work to > current_at_. > > Robert N M Watson > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Sat Apr 01 2006 - 08:32:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:54 UTC