From owner-freebsd-smp@FreeBSD.ORG Sun Sep 19 17:09:14 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92AA216A4CE; Sun, 19 Sep 2004 17:09:14 +0000 (GMT) Received: from ns0.secureanonymous.com (tjhawkins.com [64.232.254.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F41C43D45; Sun, 19 Sep 2004 17:09:14 +0000 (GMT) (envelope-from timh@tjhawkins.com) Received: from cdm-66-76-83-77.fayt.cox-internet.com ([66.76.83.77] helo=yourw92p4bhlzg) by ns0.secureanonymous.com with smtp (Exim 4.34) id 1C94GO-0007Ui-1L; Sun, 19 Sep 2004 11:10:08 -0500 Message-ID: <014101c49e6b$61dbcaa0$6401a8c0@yourw92p4bhlzg> From: To: "Robert Watson" References: Date: Sun, 19 Sep 2004 12:09:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns0.secureanonymous.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - tjhawkins.com X-Source: X-Source-Args: X-Source-Dir: cc: freebsd-advocacy@FreeBSD.org cc: freebsd-smp@FreeBSD.org cc: freebsd-questions@FreeBSD.org Subject: Re: Please explain. X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2004 17:09:14 -0000 Mr. Watson, you have addressed my questions greatly and I do agree that it will take years to successfully tackle the issue but when FreeBSD has had less funding than Linux it's obvious that it's developers have made huge progress and that I'm proud of. Your response was alot better than yelling the word troll or other things. FreeBSD is aware of the issues apparently and is working. ----- Original Message ----- From: "Robert Watson" To: Sent: Sunday, September 19, 2004 11:31 AM Subject: Re: Please explain. > > On Sat, 18 Sep 2004 timh@tjhawkins.com wrote: > > > 2 Major Issues: > > > > - FreeBSD has a processor affinity design issue > > Odd statement, but I'm not sure what it means. FreeBSD uses an SMP model > similar to that used by Sun, SGI, and other operating system and hardware > vendors who are clearly aware of affinity concerns, and who have operating > systems that scale pretty amazingly on SMP and non-SMP multi-processor > systems. > > > - The core kernel issues with FreeBSD is the horrible threading > > support.There is so much crap in FreeBSD kernel. The multithreading > > issue in freebsd has been delayed for nearly 6 years. They have just > > made work arounds, not fixing the actual problem. It seems that the only > > real BSD that has made big progress on the core issues is DragonflyBSD. > > This is also an odd statement. FreeBSD is following a well-understood and > widely implemented model for SMP scalability, although somewhat refined as > a result of starting on it after the R&D curve that Sun, IBM, SGI, HP, > etc, got to pay for. However, any major software project of this sort > takes years to complete -- Linux is only just getting to reasonable SMP > scalability after a good 6+ years of investment by some pretty major > players. Doesn't help that Linus turns down patches from SGI that help a > lot though :-). > > BTW, I've spent a lot of time looking at the DragonFly approach, and I met > with Matt for quite a while at USENIX to talk to him about the approach. I > have a number of concerns about it -- I think the premise is very > interesting, but that the results aren't yet there to prove the model. In > particular, there's a huge volume of code in their system that has not > been addressed, and a lot of complexity that will need to be handled > before the SMP primitives they're using have proven that they offer the > desired performance advantage. We have the opportunity of using a hybrid > model, and have been exploring some of the ideas present in DFBSD (and, > one should point out, many other SMP systems). > > A lot of other systems have opted to use elements similar to those > primitives, but in a much more limited way due to the performance costs. > For example, locking services into particular CPUs prevents the scheduler > from balancing load between the CPUs in an service-transparent way. In > the DFBSD model, load balancing must be implemented separately for each > service, requiring extensive modifications to the services. I.e., the > model may indeed offer benefits, but the cost of doing the work will be > high, and the time to complete it long. We'll adopt elements of the > design as they prove to make sense, as we do with all other open source > operating systems (and they do with us!). > > > It appears that FreeBSD have a clear Multi-threading lock-in issue that > > needs to be fixed. Not work arounds. According to many freebsd > > developers nobody simply wants to fix this, is it true that the current > > smp work are just 'work-arounds' not real fixing? > > > > The only thing holding FreeBSD back is the Multithreading issue. > > I think this is a pretty odd claim -- FreeBSD 5.x scales much better than > 4.x on multiple processors, allowing large parts of the kernel to run in > parallel on different CPUs. The performance results are there, showing > 1.4x - 1.6x speedup in SMP tasks with MySQL. > > I saw elsewhere in the thread that someone suggested Darwin doesn't have > SMP problems to address. Darwin is actually in an almost identical > position to us, having basic VM, kernel memory allocation, and scheduling > outside the Giant lock. They took the route of breaking the BSD parts of > their kernel into two "funnels", the network funnel, and "the rest". Our > 5.3 release will actually be much better off than Darwin on SMP by > allowing many threads of the network stack to run on different CPUs, more > support for preemption and low-latency operation. I've talked with Apple > pretty extensively about their SMP work, and met with their kernel team to > discuss their work. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Principal Research Scientist, McAfee Research > > >