Jeff Roberson has announced that he has has begun integrating the Giant-lock free VFS code into the FreeBSD 6.x development tree. These changes will permit the UFS file system to run on multiple CPUs at a time on SMP systems (hyper-threaded, dual-core, or regular SMP), leading to substantially improved efficiency. It will also permit the VFS code to be fully preemptible on uni-processor systems, improving interrupt handling latency. With this change, almost all of the FreeBSD kernel is able to run fully threaded and in parallel on multiple CPUs with much less contention. He anticipates merging this work as an “opt-in” feature to the FreeBSD 5.x branch in the future. He indicates that the testing will be “opt-in”, i.e., this change will not be fully enabled by default for the time being, and that it will take a while (a few hours) to complete the merge, so users of the 6-CURRENT branch may want to hold off updating for a few hours while he finishes the merge. The work was sponsored by Isilon Systems.
On other BSD news, BSDCan 2004 was an enormously successful grass-roots style conference.
It brought together a great mix of *BSD developers and users for a nice
blend of both developer-centric and user-centric presentations, food,
and activities. Based upon that accomplishment, planning for the next
event began shortly thereafter.
BSDCan 2005 will be held May 13-14, 2005, in Ottawa.
FreeBSD has been doing an excellent job with producing a kernel which pro-actively utilizes fine grained locking. While Giant lingers in a number of device drivers (see http://www.freebsd.org/projects/busdma/) it’s great to hear it’s being eliminated from remaining kernel subsystems.
This does lead one to ask whether Giant ended up in MacOS X when the FreeBSD UBC and VFS were ported to XNU.
I haven’t seen a single multiprocessor scalability test showing how any aspect of FreeBSD 5 scales. Why is this?
Me either anonymous, however you are welcome to conduct your own benchmark.
The thing is, a) I could never post them because I would be flamed off the planet, and b) The developers should be constantly doing their own benchmarking as they progress, but you never see results. I’ve seen lots of _claims_ that FreeBSD 5 has good scalability, so why don’t just a few benchmarks get posted ever?
Scalability isn’t that easy to test objectively. You generally need access to “mid-range” equipment (eg. quad processors with dual cores or whatever). Not many people have that sort of stuff lying around.
The developers are probably too busy developing to actually write anything up or run really conclusive benchmarks. So as someone said. There is nothing stopping you from running your own if you have the hardware.
Personally scalability means diddle to me. I don’t have an 8 way server with a terabyte of ram lying around for any OS, scalable or not.
Scalability isn’t that easy to test objectively. You generally need access to “mid-range” equipment (eg. quad processors with dual cores or whatever). Not many people have that sort of stuff lying around.
Well you can quite easily run into scalability problems on 4 ways and even somewhat on 2 way systems if you’re doing a lot of kernel intensive work. Networking, filesystem operations, etc.
You can definitely show scalability improvements on specific tests on a 4 way when starting to move from a global lock to finer grained locking.
The developers are probably too busy developing to actually write anything up or run really conclusive benchmarks. So as someone said. There is nothing stopping you from running your own if you have the hardware.
Well why not just post some raw scalability results to the -hackers mailing list once in a while. If anything you’ll help get the userbase excited and attract more developers if you show the system is undergoing all these improvements.
Personally scalability means diddle to me. I don’t have an 8 way server with a terabyte of ram lying around for any OS, scalable or not.
Well, it means a lot to some people. Including many of the FreeBSD developers and core team, right?
Even if benchmarks are *always* a good thing (provided you read them for what they are, of course), I don’t think that a benchmark right now would say anything regarding the correctness of the SMP model they chose: both BSD and Linux still have to write a lot of code before the SMP thing is finished, so drawing conclusions right now is not only premature, but just impossible.
>Well why not just post some raw scalability results to the -hackers mailing list once in a while.
Because right now it wouldn’t make sense. The FreeBSD developers say the SMP implementation is not yet optimized for performance or scalability.
The SMP model they chose required *a lot* of work: for performance and scalability we have to wait.
Given FreeBSD’s reputation, I surely hope the wait will be well worth.
This feature is very impressive!
But what about xp/w2k? Do they have this feature too? Or because of their closed source, one can only guess it/benchmark to get the answer?