I’ve read Matt’s comments on various lists since DragonFly was first announced, and in a couple of places he’s mentioned that there are a few places in DragonFly where the use of mutexes etc. would be required (an example link will be provided at the end of the post).

As has been pointed out by folks above me, many of the core bits of the kernel are nearly if not completely MP safe (network stack, slab allocator, LWKT/messaging systems etc), and are also lockless, per-cpu, serialized using threads, and employing async IPI messages to deal with things owned by other cpus.

The fact that something like a sound driver imported from FreeBSD requires locks to be MP safe hardly seems of great consequence for the time being when there is still more work being done on the kernel core to get the system to do the things that Matt wants.

Hell, I wish the BGL was no longer needed on DragonFly, but lacking anything with more than a dual core processor, I doubt I’d really see a difference under everyday workloads. It’ll be gone soon enough, and for the time being, if you really need more scalability than DF currently offers, there are plenty of systems to choose from.

http://lists.freebsd.org/pipermail/freebsd-hackers/2003-October/003800.html

“though messing with ucred’s ref count will require a mutex or an atomic bus-locked instruction even in DragonFly!”

DragonFly has three major locking primitives.. four, actually. It has critical sections for cpu-localized operations. It has real spinlocks for short bits of code. It has lockmgr locks for longer bits of code that might block. And it has tokens for very long bits of code that need to be serialized, but might block, for which we want the token to automatically be released and reqacquired by the scheduler if we block. A good example of the latter is the vnode scanner.

The issue with SMP for us is simply one of manpower. The most important primitives in the system.. the scheduler, the IPI messaging, and numerous other little bits are lock-free and run without the BGL. The I/O path and the VM path still needs the BGL. The network protocol threads still hold the BGL but will are designed to run without it and just need some attention. It’s been that way for a year, which I’m not happy with, but there are only so many hours in a day and I do have to sleep occassionally.

-Matt

-Matt

Currently dragonfly is still mostly comparable to freebsd 4 in these and other areas (although there have been a few specific features ported back from freebsd 6, such as the sound framework we have been discussing), which puts you about 7 years behind freebsd in many areas, and with a widening gap because of the difference in number of developers.

I think the benchmarking and code profiling you mention is a matter of manpower, and nothing else. This is why I am trying to steer you to the mailing lists, because critical evaluation of the code base as it changes over time would be quite useful, and welcomed by the group. I’m not dismissing your messages – I’m encouraging them! Anonymous blog comments aren’t going to be as useful as a complete debate that includes all the people involved in the project.

Perhaps the problem is that few of the dragonfly users have the technical understanding to follow the changes being made, so it results in elementary confusion like mistaking “64-bit disklabel support” for “64-bit amd64 support is now one step closer!”

In any case, the sound code originally in question here was ported from FreeBSD by a different developer.

These are the questions you guys should be asking yourselves instead of just taking Matt’s word as golden.

Lockmgr locks are a form of mutex (what else), and they are approximately as efficient (when uncontended) as spinlocks.

Furthermore, the sound subsystem does not have to be highly optimized for MP performance. There is few potential to split data structures between CPUs and it will rarely be accessed concurrently. Not reworking the locking paradigm is very economic, because more code updates can be easily imported from FreeBSD.

Thus, perfect choice to use lockmgr locks.

Don’t feed the troll! Or, wait… maybe some rotten eggs?

P.S.
For those unaware, this comment was made in jest.

As for porting code from FreeBSD, spinlocks and LWKT serializers are very good alternatives in practical use.

I’m not qualified to assess how valid your description of lockmgr is. The only point made so far is that

1: DragonFly BSD is somehow invalidated as an entire project because

2: a developer committed ported code that, by your definition, matches a locking type that another (not directly quoted) developer didn’t like.

The people you are naming/quoting in this discussion are not present; this discussion is not going to lead to anything useful until you engage the actual people involved. I’m not doing this to be defensive; if there’s a problem in the way the system is being built, it’s good to get it discussed and out in the open. These blog comments won’t do that.

Unfortunately lockmgr is about the worst possible implementation of a synchronization primitive to use in low-level kernel code. It is about two orders of magnitude too slow, bloated and inefficient for the job.