Date: Fri, 9 Aug 2002 12:44:11 -0400 From: "Kevin A. Pieckiel" <kpieckiel-freebsd-stable@smartrafficenter.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Mario Pranjic <mario.pranjic@irb.hr>, freebsd-stable@FreeBSD.ORG Subject: Re: SMP kernel: FreeBSD vs. Linux 2.4.x Message-ID: <20020809164411.GC78503@pacer.dmz.smartrafficenter.org> In-Reply-To: <20020809091008.A87124@unixdaemons.com> References: <Pine.GSO.4.32.0208091409570.6242-100000@nippur.irb.hr> <20020809091008.A87124@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 09, 2002 at 09:10:08AM -0400, Bosko Milekic wrote: > I don't know about Linux 2.4.x. However, FreeBSD -STABLE employs > a "Big Giant Lock" around the kernel, so that if you have two > processes that want to do work in the kernel (e.g., system call), one > will have to wait for the other to leave the kernel before it does > anything. [snip] > 5.0 will ship with the infrastructure of a multi-threaded kernel. > However, it will take a few releases before you can really see the big > advantages it brings. 5.0 will also bring a hoard of new things that > will take some time to settle and become really useful. Notably, KSEs > will allow for some really flexible/performant threading once they > settle in. Several in-kernel mechanisms will also become more and > more advantageous as the Giant lock is further unwound. A few questions on this issue. First, what was the reasoning behind making the whole kernel a critical code segment? I can't think of any reason kernel developers would have to design the kernel this way, shy of sheer laziness or such profound architectural changes being necessary to impliment it otherwise. In either case, I see both mindsets leading to the "we'll fix it later" path early in kernel development, and I'm sure the developers knew full well it would be harder to fix later rather than sooner. Of course, not being a kernel developer, I couldn't even begin to fathom all that is involved in such changes, so I truely am speaking from ignorance on the subject. Any enlightening thoughts to help me understand this bit? Second, what are KSEs? Also, I've done quite a bit of coding threading non-threaded code and developing threaded code from scratch. I know that it can be an enormous project for something like the FreeBSD kernel if the kernel didn't begin with multithreading in mind. But why was the kernel not threaded from the start? Threads aren't a new concept, and when FreeBSD was born, it would make sense to consider the advantages threads bring to userland code when determining how the future of the kernel will unravel. Those advantages would seem desirable for the kernel as well, would they not? Again, I speak from ignorance of the internal workings/structure of the kernel. I'm not trying to fault anyone for these early decisions, just get a clearer picture of why it was developed this way. Kevin Forgiveness is not an occasional act; it is a permanent attitude. -- Martin Luther King Jr. --- This message was signed by GnuPG. E-Mail kpieckiel-pgp@smartrafficenter.org to receive my public key. You may also get my key from wwwkeys.us.pgp.net; my ID is 0xF1604E92 and will expire on 01 January 2003. --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9U/FZc3iJbvFgTpIRAg/eAJ90ytu4H+xpEtkWUfSCsi9riLaoxQCfe5XO tpFGzUxyrdKxxklwdJAXjuw= =M6zp -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020809164411.GC78503>