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 a...@.
04 July 2007 yes Disconnect parts of I4B from the build. HEADS-UP to
i...@.
17 July 2007 yes Post NET_NEEDS_GIANT() reminder to a...@.
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.
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
