Simon ‘corecode’ Schubert has added his patch to allow separate volume control for each application. Also, Hasso Tepper has produced a patch for sound that includes changes taken from FreeBSD 6, which improves device support.
23 Replies to “More sound updates”
Comments are closed.
Big thanks, Hasso! Can’t wait to try this and see if it gets the SB600’s HDA up and running.
Also, since I’m in the habit of stuffing pointers to completely off-topic items in obscure places, lately, I just noticed Linux’s “binfmt_misc” feature, which is sort of novel. Perhaps it would be better implemented as a shell patch, although I think this means you could use e.g. a Java bytecode login-replacement or inetd-using daemon if you wanted to.
http://en.wikipedia.org/wiki/Binfmt_misc
(Hmm, what’s correct terminology for a daemon that relies on inetd? Or was that the original conception of ‘daemon,’ when the need to support multiple connections wasn’t common case?)
Oh..wow, you’re using lockmgr locks as a basic SMP primitive? That’s a tacit admission of the failure of the dragonfly SMP model if ever there is one.
Regarding the lockmgr comment – It’d probably be better to take a comment like that to the kernel@dragonflybsd.org mailing list – in part because there will be people there who can specifically discuss the merits of your statement, and in part because an anonymous comment off of a post about sound support seems a lot like a troll.
You’re volunteering to implement a better suitable primitive for sound? Which is not that nice, because it would be the only subsystem using that primitive at that point, but well. Please de-anonymise?
No, that’s your job to implement :) lockmgr is being used here as a way to stealthily avoid implementing mutexes. As long-time project observers know, back when SMP was still something that seemed achievable in dragonfly, Matt was extremely vocal in his insistance that mutexes are not necessary in the dragonfly SMP model and would not be added to dragonfly. He partially reneged on that claim when he added spinlocks (a form of mutex), and now he is apparently using lockmgr locks as mutexes to avoid giving that final inch of ground by adding an efficient sleep mutex implementation. For example, this will be useful in all the code being ported from freebsd.
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.
When you won’t post who you are, it makes it difficult to take your comments seriously.
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.
It’s OK, I’m not expecting to change the opinions of any of the true believers. Those of you who care objectively about dragonfly will have to address this problem sooner or later though.
His points were against the mutex model chosen by the FreeBSD project, not the academical abstraction of a mutex. That’s how I understood it at least. Also, DragonFly lockmgr locks aren’t identical to FreeBSD 4.x (and 5.x?) lockmgr locks, they’ve been simplified and adapted more towards the serializers since. I don’t know when exactly, but at least one release ago, so more than half a year ago.
As for porting code from FreeBSD, spinlocks and LWKT serializers are very good alternatives in practical use.
Oh and btw, this is sound we’re talking about. Who the fuck cares?!? ;)
P.S.
For those unaware, this comment was made in jest.
Anonymous is obviously a clueless, ignorant person. So, for everybody really intersted in the points raised:
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?
But apparently the existing primitives are not good enough in this instance. And if Matt is not opposed to adding a mutex primitive, why doesn’t he just do that instead of severely abusing lockmgr? If you are claiming that dragonfly’s lockmgr is in fact efficient enough to use in this way, where are your measurements that demonstrate this?
These are the questions you guys should be asking yourselves instead of just taking Matt’s word as golden.
Matt’s not here saying anything, so we have no word to take as golden. This is why I suggest taking this to the mailing lists, so that you can address him directly.
In any case, the sound code originally in question here was ported from FreeBSD by a different developer.
Simon, I’d appreciate references to benchmarks supporting your assertion that lockmgr locks are approximately as efficient as spinlocks. Based on an inspection of the code I believe it to be completely untrue, and your simply asserting it does not make it so.
Justin, Matt was the one who converted from spinlocks to lockmgr, and no-one called him on it. Unfortunately that is the level of uncritical acceptance that appears to be common in the dragonfly community. There is a lack of critical introspection and analysis through benchmarking and code profiling that is raising a large barrier for dragonfly to become performance competitive with other operating systems. Regardless of whether you choose to dismiss my messages, it is self-evident that this process is necessary to guide development.
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!”
The same thing holds true for FreeBSD users, as I haven’t met anyone of them yet who isn’t either clueless or a dramaqueen.
TGEN, attempting to deflect the criticism with “oh yeah, well so are you!” is childish. If you acknowledge that the problem is real, then the way to proceed is to do better, not to claim that everyone else is just as bad so that makes it OK.
Hey, you’re right – I mistook the disklabel work for something else. I modified the post to note this.
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.
I am not a dragonfly user or developer, just an interested observer. As such I am not going to take a role in performing this work myself. It is an effort that will need to come from within the dragonfly user community: you guys need to find a way to become more efficient with the resources you have, because the alternative is to fall further and further behind other operating systems in critical usability areas like performance and support for modern hardware.
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.
Well, first of all, we are faced with a relatively huge job reworking the sound code’s locks properly and frankly it is not #1 on my priority list. Secondly, spinlocks (or mutexes in the case of the code in FreeBSD) are used entirely inappropriately by the sound module… they are being used to lockup *HUGE* swaths of code and for all intents and purposes they might as well be heavy weight locks. Third, this is a *sound* driver we are talking about here. Performance isn’t really an issue except insofar as it interferes with itself. And, finally, from a performance standpoint lockmgr locks (particularly ours, which have been cleaned up considerably from the cruft we inherited) are only going to be a nanosecond or two slower then a spinlock anyhow, which is pretty irrelevant when it comes to a sound device.
-Matt
Insofar as mutex primitives go… I’m not sure if the poster realizes that mutexes and lockmgr locks are virtually the same thing in FreeBSD. The core of the code is about the same either way… fast if it isn’t contended, and slower if it is. There are minor scheduler differences with regards to how things block, but that’s it. DragonFly doesn’t need mutexes, because it has lockmgr locks, and our scheduler is far less heavy weight then FreeBSDs so it just isn’t that big a deal to block.
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 was extremely vocal in his insistance that mutexes are not necessary in the dragonfly SMP model and would not be added to dragonfly. He partially reneged on that claim when he added spinlocks (a form of mutex), and now he is apparently using lockmgr locks as mutexes to avoid giving that final inch of ground by adding an efficient sleep mutex implementation.”
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!”
Я конечно в Ñтом не оÑобо разбираюÑÑŒ, но поÑле вашей Ñтатьи Ñтал гораздо больше понимать. БлагодарÑтвую :)