OSNews reader Jim Strawberry writes: "The BSDvault guys did an interview with Jordan Hubbard not to long ago -- unfortunately it was done as an IRC conversation and was posted as such -- making it rather hard to read & follow. For this reason it didn't really get much attention. The other day I took it upon myself to transform this IRC log into a real interview." Jim received authorization by the original posters, BSDVault, and asked us to publish his revised and cleaned-up version of the interview with Apple's & FreeBSD's Jordan Hubbard.BSDVault: We have all heard rumours about the upcoming FreeBSD 5.0 and the new features it will have. The most discussed and anticipated is probably SMPng and filesystem improvements. What do you feel is the "coolest" new feature, and which feature/improvement do you think will be the most noticable? Is SMPng and background fsck along with the filesystem tweaks really all it's cracked up to be? Will FreeBSD be able to compete with other os'es that are typically used on multiple-cpu machines, such as Solaris and HP-UX, when it comes to SMP performance?
Jordan Hubbard: I think the coolest feature of 5.0 will be the ferret thread. This is a kernel thread which runs around throughout the system and randomly moves things around, playfully changes file modes, "bites" through open connections and just generally raises havok. We feel that this feature will make the computer more of a pet than a simple inanimate object.
Sorry. To be honest, I really don't expect 5.0 to be something which really stands out to anyone but geeks. In other words, if it's done correctly there will be very little visible impact, though there will hopefully be some visible performance gains. The biggest advance will be internally, how things are put together and how scalable the internal mechanisms are. This will allow 5.1 and other 5.x releases to perhaps be much more visibly impressive in some way.
What is the current status of SMPng? How do you think SMPng will fair against Linux 2.4.x's SMP support when it is stable?
Well, if I had to sum it up in a nutshell, I would say "on target, though late". The aims of SMPng are pretty grandiose; The complete multi-threading of the kernel, a rewrite of the scheduler, full preemptability and fine-grained resource locking. Naturally, everyone wanted to tackle all of the classic problems with making SMP scalable, not just one of them. So far, interrupt threading is working very well and a lot of the finer-grained locking has been done or is in progress. The scheduler rewrite is about to hit its first major milestone with KSE 3, which will be presented and discussed at BSDCon. What remains now is a lot more irritating lock-pushdown work and performance improvements to some of the locking code. I think that in around 6 months, it will be very fair to compare it to the Linux 2.4.x code, I'm hoping even superior in a number of ways (both from a performance and a stability perspective).
Doesn't having a fully preemtable kernel add the possibility of reducing overall data throughput? That's what the Linux pre-emption code seemed to do.
No, since you're not going to change reality. Fundamentally just because you can be preempted, you frequently are. It just makes it possible to deal with real-time and asyncronous events in a much cleaner and more natural fashion. I don't expect it to affect overall data throughput.
How do you deal with interrupts being disabled / locks being held for long time with preemption ?
1. You don't disable interrupts for a long time.
2. In the worst case where you're contesting a lock, you generally just get put back to sleep and the preemption essentially refused. Though, of course, you'd be instrumenting the hell out of the kernel in order to find those sorts of lock contentions and fix them.
What do you think about TrustedBSD on Freebsd 5.0?
I think TrustedBSD will continue to merge code into 5.x; That's their charter. Other than that, it's up to them to set their schedule.
Is the drm-kmod (hardware support for XFree86 4.x DRI) port going to be integrated into the core kernel/modules in 5.0?
I don't specifically know if this is planned for 5.0, but I can say that critical mass for such a thing certainly seems to be building and it's something which could easily get done in time for 5.0 -- I use it myself with a Matrox G400 card and it rocks!
Does anything stand-out that is on radar for post 5.0?
I'm interested in what having a truly preemptable kernel will allow. It means there will be a potential for real-time applications, and perhaps interesting A/V work for example. Being able to leverage multiple CPUs in a truly useful way will make the n-way stuff much more interesting, whether it's n-way internally (inside the CPU itself) or externally.
