[vsrinivas]

Still hard to say.

In the network stack, I think the DragonFly approach is definitely better (than fine-grained data structure locking). In DF, connections are routed to per-CPU network service threads based on a consistent hash; as a connection will always route to the same CPU, locking requirements are simpler. There are some places where the 'lower-half' network code does unfortunately take locks (when delivering data to socket buffers), but on the whole it's a good design. Solaris chose the same model, called it FireEngine; they have more writeups, if you're interested.

The changes in the 3.2 release that improved PostGres/pgbench performance were just good-old-fashioned lock breaking (spreading UNIX domain socket locking out), bypassing inefficient paths when possible (ex: bypass instantiating a buffercache buffer when data can be read directly from the page cache), and the new scheduler work. One other change was a neat trick, a form of page-table sharing; many of those changes would make sense on FreeBSD or similar systems.

The page-table sharing work addressed a problem seen years ago in Linux -- the cost of pv_entry manipulations. Linux moved from rmap to objrmap (http://lwn.net/Articles/75198/); FreeBSD reduced the cost of pv_entries by reducing their size and packing them densely. DFly's page-table sharing reduced the number of pv_entries (basically de-duped them) in particular situations (correct alignment/size of matched mapping; SHM segments, like in X or PostGres benefit most).