6 Replies to “CAM locking tests”

1. Uh…using lockmgr? What a good way to cripple dfly performance further. Dillon just needs to own up to reality and admit that an optimized mutex primitive has its place, instead of encouraging people to use an extremely bloated and heavy-weight primitive that can simulate a mutex at the cost of enormous performance overhead.

2. “Yah, I far prefer that people use lockmgr locks for most porting from FreeBSD, if only to make debugging far, far easier. They aren’t half bad… over the years I’ve removed a lot of cruft from the lockmgr API, it’s actually pretty efficient.”

   http://leaf.dragonflybsd.org/mailarchive/submit/2008-01/msg00013.html

3. I claim that assertion is false. Where are Matt’s benchmarks showing that the lockmgr primitive is “pretty efficient”? Saying it doesn’t make it so.

4. For that matter, where are Peter’s benchmarks showing that his changes improve performance? If he doesn’t know whether they improve performance, why is he proposing them? Why is no-one from the dragonfly community asking these questions?

5. He’s doing these changes because the old code would cause lockups. His new code does not. That’s efficient.

   Anonymous responses on a web page is just about the best way possible to look like someone with an ax to grind, and without an ability to discuss things rationally. Please post with your actual name or take it to the DragonFly mailing lists if you want to have genuine discussion of these issues.

6. The content of my posts has nothing to do with the name I choose to attach to them. Feel free to continue ignoring the issues I raised, it is no skin off my nose if dragonfly continues to lose performance over time because no-one is making sure the ship is pointing in the right direction.

Comments are closed.