"I and the other Kernel.org admins would like to announce downtime for ALL kernel.org machines (this includes all of the mirror machines, the public machines and the backend master). The downtime is scheduled to start on or around April 2nd, 2008 on or around 0001 UTC," began a GPG signed message on the Linux kernel mailing list from John 'Warthog9' Hawley, one of the kernel.org admins. Referencing a recent Slashdot discussion that compared Linux and FreeBSD performance, he continued:

"After much deliberation, research and argument in #korg (along with screaming matches between HPA and I over dinner) we are upgrading the kernel.org machines from Fedora Core 5 to FreeBSD 7.0. This decision does not come lightly to the Kernel.org admins, and we would like to point out several key things that helped us form our decision:"

John concluded, "we feel that we can better serve our mirrors, our users and the community by making the switch, and we hope to have the transition done very shortly."

"Google Summer of Code 2008 is on! Over the past three years, the program has brought together over 1500 students and 2000 mentors from 90 countries worldwide, all for the love of code. We look forward to welcoming more new contributors and projects this year," begins a page listing all the projects planning to participate in this year's GSoC. Among the numerous planned participtants there are many kernel projects, including DragonFly BSD, FreeBSD, Git, GNU/Hurd, Linux, Minix, and NetBSD.

Student applications for GSoC projects begin today, running through the end of the month. Read on for many of the participation announcements from the above projects. For more information about the GSoC, the program's FAQ explains:

"Google Summer of Code (GSoC) is a program that offers student developers stipends to write code for various open source projects. Google will be working with a several open source, free software, and technology-related groups to identify and fund several projects over a three month period. Historically, the program has brought together over 1,500 students with over 130 open source projects to create millions of lines of code. The program, which kicked off in 2005, is now in its fourth year."

"I'd like to send a small update on my progress on the Performance Tracker project," noted Erik Cederstrand on the FreeBSD -current mailing list. He continued, "I now have a small setup of a server and a slave chugging along, currently collecting data. I'm following CURRENT and collecting results from super-smack and unixbench." The project performs regular benchmarks of the FreeBSD -current source tree using Unixbench and Super Smack, allowing you to chart the results over time. Erik highlighted an example of a visible change in performance when the generic kernel moved from the 4BSD scheduler to the ULE scheduler on October 19th, 2007.

Kris Kennaway responded favorably, then noted, "one suggestion I have is that as more metrics are added it becomes important for an 'at a glance; overview of changes so we can monitor for performance improvements and regressions among many workloads." He went on to suggest, "at some point the ability to annotate the data will become important (e.g. 'We understand the cause of this, it was r1.123 of foo.c, which was corrected in r1.124. The developer responsible has been shot.")" Erik agreed with both recommendations, and noted that he would continue to work in that direction.

A recent thread on the FreeBSD -current mailing list discussed the stability of ZFS on FreeBSD. Scott Long noted that ZFS requires proper tuning to be stable:

"I guess what makes me mad about ZFS is that it's all-or-nothing; either it works, or it crashes. It doesn't automatically recognize limits and make adjustments or sacrifices when it reaches those limits, it just crashes. Wanting multiple gigabytes of RAM for caching in order to optimize performance is great, but crashing when it doesn't get those multiple gigabytes of RAM is not so great, and it leaves a bad taste in my mouth about ZFS in general."

ZFS was committed in April of 2007 by Pawel Dawidek who notes that he is using ZFS quite successfully on all of his systems. He then cautioned, "of course all this doesn't mean ZFS works great on FreeBSD. No. It is still an experimental feature." In response to some negative comments about ZFS on FreeBSD, Pawel noted, "in my opinion people are panicing in this thread much more than ZFS:) Let try to think how we can warn people clearly about proper tunning and what proper tunning actually means. I think we should advise increasing KVA_PAGES on i386 and not only vm.kmem_size. We could also warn that running ZFS on 32bit systems is not generally recommended."

"This report covers FreeBSD related projects between July and October 2007," began the latest FreeBSD Quarterly Status Report, posted by Brad Davis. He included a summary of the recent Google Summer of Code projects noting, "lots of participants are working getting their code merged back into FreeBSD." Regarding the upcoming FreeBSD 7.0 release he noted, "the bugs in the FreeBSD HEAD branch are being shaked out and it is being prepared for the FreeBSD 7 branching. If your are curious about what's new in FreeBSD 7.0 we suggest reading Ivan Voras' excellent summary."

Among the many projects discussed in the status report was work by Marko Zec on network stack virtualization, "the network stack virtualization project aims at extending the FreeBSD kernel to maintain multiple independent instances of networking state. This allows for networking independence between jail-like environmens, each maintaining its private network interface set, IPv4 and IPv6 network and port address space, routing tables, IPSec configuration, firewalls, and more." Another project discussed was the porting of Linux KVM, "a software package that can be used to create virtual machines fully emulating x86 hardware on top of machines supporting Intel VT-x or AMD-V virtualization extensions." The report noted, "Linux KVM has been ported to FreeBSD as a loadable kernel module, using the linux-kmod-compat port (in /usr/ports/devel/) to reuse as much as possible of the original source code, plus an userspace client consisting in a modified version of qemu, that uses KVM for the execution of its guests."

Andrew Doran posted some threading benchmark results to NetBSD's tech-kern mailing list, following up to some benchmarks he'd posted earlier. The results compared NetBSD -current with FreeBSD -current, and the Linux 2.6.21 kernel. Kris Kennaway was surprised by the results, and ran his own benchmarks with minimal configuration changes, summarizing, "this measurement shows that FreeBSD is performing 70-80% better than NetBSD in this 4 CPU configuration. This is in contrast to Andrew's findings which seem to show NetBSD performing 10% better than FreeBSD on a 4 CPU system (a very old one though)." He added, "the drop-off above 8 threads on FreeBSD is due to non-scalability of mysql itself. i.e. it comes from pthread mutex contention in userland."

Kris ran additional benchmarks with PostgreSQL instead of MySQL, showing much improved scalability above 8 threads, "postgresql is much more scalable than mysql on this workload and doesn't have silly scaling bottlenecks inside the application (cf the tail of the FreeBSD curve for mysql which is where pthread mutex contention kicked in)." He continued his testing, and found that on older 4CPU P3 hardware NetBSD did outperform FreeBSD, "but only by 3-4% (in particular I am not seeing the ~10% difference that Andrew observes on his 4*p3 700MHz). Given the age of the hardware and the fact that I am not seeing it on other workloads or on modern hardware it might just be due to a small scheduling difference on this configuration."

A potential bug reported against the Completely Fair Scheduler suggested that it was causing a network slowdown, measured with the 'Iperf' bandwidth performance benchmarking tool. The performance hit was quickly tracked to the previously discussed changes in how CFS handles sched_yield(). When it was suggested that this was a bug in the new process scheduler, Ingo explained:

"I had a quick look at the source code, and the reason for that weird yield usage was that there's a locking bug in iperf's 'Reporter thread' abstraction and apparently instead of fixing the bug it was worked around via a horrible yield() based user-space lock."

He then submit a small patch to fix the bug and remove the call to sched_yield() resulting in, "iperf uses _much_ less CPU time. On my Core2Duo test system, before the patch it used up 100% CPU time to saturate 1 gigabit of network traffic to another box. With the patch applied it now uses 9% of CPU time." He added playfully, "sched_yield() is almost always the symptom of broken locking or other bug. In that sense CFS does the right thing by exposing such bugs =B-)" Stephen Hemminger pointed out that a similar patch had been submitted to the Iperf project last month as it caused an identical problem with FreeBSD's scheduler.

"Congratulations to the successful students and their FreeBSD Project mentors for participating in another productive Google Summer of Code," Murray Stokely noted on the -announce FreeBSD mailing list. He offered an interesting summary of all of this year's student projects, adding:

"This program encourages students to contribute to an open source project over the summer break with generous funding from Google. We have had a total of over 50 successful students working on FreeBSD as part of this program in 2005, 2006, and 2007. These student projects included security research, improved installation tools, filesystems work, new utilities, and more. Many of the students have continued working on their FreeBSD projects even after the official close of the program. We have gained many new FreeBSD committers from previous summer of code projects already, and more are in the process."

Matthew Dillon created DragonFly BSD in June of 2003 as a fork of the FreeBSD 4.8 codebase. KernelTrap first spoke with Matthew back in January of 2002 while he was still a FreeBSD developer and a year before his current project was started. He explains that the DragonFly project's primary goal is to design a "fully cross-machine coherent and transparent cluster OS capable of migrating processes (and thus the work load) on the fly."

In this interview, Matthew discusses his incentive for starting a new BSD project and briefly compares DragonFly to FreeBSD and the other BSD projects. He goes on to discuss the new features in today's DragonFly 1.10 release. He also offers an in-depth explanation of the project's cluster goals, including a thorough description of his ambitious new clustering filesystem. Finally, he reflects back on some of his earlier experiences with FreeBSD and Linux, and explains the importance of the BSD license.

A recent security advisory announced today by Rapid7 explains, "the NVIDIA Binary Graphics Driver for Linux is vulnerable to a buffer overflow that allows an attacker to run arbitrary code as root. This bug can be exploited both locally or remotely (via a remote X client or an X client which visits a malicious web page). A working proof-of-concept root exploit is attached to this advisory." The advisory goes on to note that the FreeBSD and Solaris binary drivers are also likely vulnerable to the same flaw and cautions, "it is our opinion that NVIDIA's binary driver remains an unacceptable security risk based on the large numbers of reproducible, unfixed crashes that have been reported in public forums and bug databases."

Chad Loder [bio], Rapid7's Manager of Engineering, explained that NVIDIA has known about this bug in their binary driver for some time, "the link in the advisory is the earliest thread in which we could find an NVIDIA employee publicly acknowledging the bug, although it was reported back in 2004 and has probably existed even longer." Regarding the decision to announce the exploit to the public Chad explained, "I expect (or hope) that NVIDIA will fix the defect in their binary drivers quickly. I don't know anything about their development process or where their Linux drivers fit into their priority list. It seems that the majority of Linux users are perfectly willing to accept bugs in binary blob drivers from hardware vendors, so there is little incentive for NVIDIA to change their process."

The upcoming release of OpenBSD 3.3 on May 1'st will include, among many other improvements, a notably enhanced version of PF, OpenBSD's stateful packet filter. Some of the more significant enhancements to PF include: 'queues', allowing for per-rule bandwidth control [story]; 'pool options', allowing one to utilize multiple uplinks and to intelligently redirect traffic to multiple servers; 'anchors', which allow one to divide packet filtering rule lists into logical pieces; 'tables', efficiently allowing for very large lists; and other parser improvements that make an already friendly syntax more human readable.

PF replaced its predecessor, IPF, with the release of OpenBSD 3.0 in December of 2001. Since that time, this impressive and relatively new packet filter has grown a faithful following (myself included), and continues to evolve rapidly with each new OpenBSD release. Perhaps the greatest compliment, developers have begun to port PF to other operating systems. Back in January, Joel Wilsson announced his effort to port PF to NetBSD. And more recently, Pyun YongHyeon announced his port for FreeBSD.

I approached Pyun to learn more about his recent porting efforts. In the following article he explains why he began working on this port, and what FreeBSD users can expect from the project. Additionally, I spoke with PF creator Daniel Hartmeier [interview], PF developer Henning Brauer, and OpenBSD creator Theo de Raadt [interview]. They all reflect on these recent porting efforts, as well as the exciting new features found in OpenBSD's PF.