Please explain.

timh at tjhawkins.com timh at tjhawkins.com
Sun Sep 19 10:09:14 PDT 2004


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" <rwatson at FreeBSD.org>
To: <timh at tjhawkins.com>
Sent: Sunday, September 19, 2004 11:31 AM
Subject: Re: Please explain.


>
> On Sat, 18 Sep 2004 timh at 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 at fledge.watson.org      Principal Research Scientist, McAfee
Research
>
>
>



More information about the freebsd-questions mailing list