Date: Sun, 19 Sep 2010 19:33:14 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Vadim Goncharov <vadim_nuclight@mail.ru> Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon Message-ID: <alpine.BSF.2.00.1009191922570.86826@fledge.watson.org> In-Reply-To: <opviol28ky17d6mn@nuclight> References: <201009011653.o81Grkm4056064@fire.js.berklix.net> <201009011902.06538.hselasky@c2i.net> <alpine.BSF.2.00.1009051144190.47367@fledge.watson.org> <slrni8c5gj.1eap.vadim_nuclight@kernblitz.nuclight.avtf.net> <4C8627A6.1090308@icyb.net.ua> <opviol28ky17d6mn@nuclight>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Sep 2010, Vadim Goncharov wrote: >> Which part of "support for the Giant lock *over the network stack* was >> removed" [emphasis mine] do you not understand? > > No, component removed was (1), I've underlined. > >> The reason is performance for overall network stack, not ideology. > > For a practical reasons, "it works but slow" is better than "doesn't work at > all (due to absence of code in the src tree)". > > "Make it work. Make it right. Make it fast. In that order", know this? > Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is > it?.. Doug has already clarified, but just to follow up with some detail: Moving to a parallel network stack required that all portions of the stack code be updated to operate without the Giant lock present -- the Giant lock was a fundamental assumption in all kernel code in FreeBSD 4.x and earlier. This decade-long project was highly successful, and relied on members of the community stepping forward to adapt a very large code base by adding fine-grained locking to each component. The results have been extremely impressive, allowing our network stack to scale to 8+ CPUs (I'm actually testing with 32-thread systems as part of some network stack work I'm doing right now). Towards the end of the project, it was clear that a few components in the stack had attracted no interest from the community, and as such, were not going to get updated. As such, we went through a public deprecation and removal process, in which we appealed repeatedly for community members to update the code. This included i4b, one of our three ATM implementations, and one of our two IPSEC implementations. I've attached the i4b schedule below (a three-year process), but you can find information on the full process here: http://wiki.freebsd.org/NONMPSAFE_DEORBIT This was not an issue of i4b operating more slowly than the rest of the stack: it was that the code required fundamental architectural changes without which it couldn't compile, let alone run. We're all happy to have ISDN support come back in the tree if there's an owner for doing it! In the end, any significant code base in the kernel requires ownership -- it can continue through many minor changes without an owner, but major retrofits, such as moving to fine-grained locking, need the attention of someone who understands the code, is able to test the code, and has the time to invest in the code. We do a pretty good job at arranging this with a multi-million line code base, all told. Robert Date Done Event 18 July 2005 yes Post MPSAFE network stack plan to arch@. 04 July 2007 yes Disconnect parts of I4B from the build. HEADS-UP to isdn@. 17 July 2007 yes Post NET_NEEDS_GIANT() reminder to arch@. 27 July 2007 yes Remove NET_NEEDS_GIANT(). 22 March 2008 yes Last call to seek for help rewriting I4B to keep it alive. 15 May 2008 yes Final announcement on isdn@ that I4B will be removed from 8/7. 26 May 2008 yes Remove i4b from HEAD.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1009191922570.86826>