Comments on: CAM locking tests

By: Anonymous

Anonymous — Tue, 11 Mar 2008 08:07:25 +0000

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.

By: justin

justin — Tue, 11 Mar 2008 04:23:00 +0000

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.

By: Anonymous

Anonymous — Mon, 10 Mar 2008 13:29:39 +0000

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?

By: Anonymous

Anonymous — Mon, 10 Mar 2008 13:13:57 +0000

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.

By: Anonymous

Anonymous — Mon, 10 Mar 2008 11:43:44 +0000

“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

By: Anonymous

Anonymous — Mon, 10 Mar 2008 11:06:06 +0000

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.