5 ms·

DragonFlyBSD 3.2 Release

43 points by conductor 14y ago

neverm0re 14y ago
Congrats to Dillon and the rest of the awesome members of the Dragonfly team, looking forward to testing the Postgres improvements. This is the most exciting BSD distribution at the moment for me!
- rohshall 14y ago
  I tried Dragonfly BSD a month ago. I found some essential ports did not work and I could not install the development software I needed. I wish they establish their own ports soon instead of piggybacking on NetBSD or improve the reliability of the existing ports. Also, DF BSD is too focused on filesystems (and in general, all BSDs seem to share this trait) and less focused on a desktop user experience.
  - neverm0re 14y ago
    And what exactly is wrong with working on something as forward-thinking as HAMMER2? (http://leaf.dragonflybsd.org/mailarchive/users/2012-02/msg00020.html http://leaf.dragonflybsd.org/mailarchive/users/2012-02/msg00...) DragonflyBSD's team is very small. Roughly fifteen people really active people if I recall? Only fifty people listed as contributors. It's smaller than any other major BSD, it's smaller than any of the major Linux distros by a substantial margin while also biting off more work as they're developing the entire operating system as a whole. That means you need to make tradeoffs like using NetBSD's pkg_src so you can free up time to work on more interesting things. Packages might break, but the intended audience at the moment for DragonflyBSD is very likely already familiar with building from source and comfortable supporting themselves, certainly with setting up a desktop on their own. I'd suggest looking later when HAMMER2 is out of the gate and they have more time to focus elsewhere, the ports situation certainly wouldn't be forever. (especially with help)
    - rohshall 14y ago
      I understand and appreciate the great work DragonFly BSD team is doing. I am just pointing out my less-than-satisfactory experience with the ports system I got FreeBSD and OpenBSD installed successfully on my laptop. Also, if I remember correctly, I tried building from ports as well. On some ports, I got the error that they are not supported for DragonFly. When I could not get OpenJDK port working, I just gave up because it is essential for me to have it working.
      - jrmarino 14y ago
        OpenJDK 7 has been building natively on both DragonFly platforms for a few months now. It's possible that the most current pkgsrc branch release, 2012Q3, is the first one where openJDK 7 works (maybe Q2, but I can't remember exactly when it was fixed). And you might get your wish on dedicated DragonFly ports... [teaser]
  - TallGuyShort 14y ago
    I'm really sick of people ragging on the BSD's for their bad user experience. Dragonfly BSD has as its explicit goal to try develop ideas for a cluster operating system. Where did you get the idea that they were trying to deliver BSD on the desktop? Try PC BSD if that's what you want.
alberth 14y ago
How did the DragonFlyBSD team performance benchmark [1] against Postgres version 9.3 when the latest stable release is 9.2.1 and no development release of 9.3 is available? [1] http://lists.dragonflybsd.org/pipermail/users/attachments/20121010/7996ff88/attachment-0002.pdf http://lists.dragonflybsd.org/pipermail/users/attachments/20...
- neverm0re 14y ago
  Postgres 9.3-devel: http://www.postgresql.org/docs/devel/static/install-getsource.html http://www.postgresql.org/docs/devel/static/install-getsourc...
- vsrinivas 14y ago
  That these benchmarks were done with 9.3-devel was important; part of what triggered this work was PostGres moving to a different way of mapping it's shared memory segment (mmap vs shm), the benchmarks were initially done to see how much that hurt.
alberth 14y ago
In hindsight now, was Dillon correct in his approach to SMP & threading implementation over FreeBSD 5's approach?
- vsrinivas 14y ago
  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/ 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).

43 points by conductor 14y ago

Congrats to Dillon and the rest of the awesome members of the Dragonfly team, looking forward to testing the Postgres improvements. This is the most exciting BSD distribution at the moment for me!

rohshall 14y ago
I tried Dragonfly BSD a month ago. I found some essential ports did not work and I could not install the development software I needed. I wish they establish their own ports soon instead of piggybacking on NetBSD or improve the reliability of the existing ports. Also, DF BSD is too focused on filesystems (and in general, all BSDs seem to share this trait) and less focused on a desktop user experience.
- neverm0re 14y ago
  And what exactly is wrong with working on something as forward-thinking as HAMMER2? (http://leaf.dragonflybsd.org/mailarchive/users/2012-02/msg00020.html http://leaf.dragonflybsd.org/mailarchive/users/2012-02/msg00...) DragonflyBSD's team is very small. Roughly fifteen people really active people if I recall? Only fifty people listed as contributors. It's smaller than any other major BSD, it's smaller than any of the major Linux distros by a substantial margin while also biting off more work as they're developing the entire operating system as a whole. That means you need to make tradeoffs like using NetBSD's pkg_src so you can free up time to work on more interesting things. Packages might break, but the intended audience at the moment for DragonflyBSD is very likely already familiar with building from source and comfortable supporting themselves, certainly with setting up a desktop on their own. I'd suggest looking later when HAMMER2 is out of the gate and they have more time to focus elsewhere, the ports situation certainly wouldn't be forever. (especially with help)
  - rohshall 14y ago
    I understand and appreciate the great work DragonFly BSD team is doing. I am just pointing out my less-than-satisfactory experience with the ports system I got FreeBSD and OpenBSD installed successfully on my laptop. Also, if I remember correctly, I tried building from ports as well. On some ports, I got the error that they are not supported for DragonFly. When I could not get OpenJDK port working, I just gave up because it is essential for me to have it working.
    - jrmarino 14y ago
      OpenJDK 7 has been building natively on both DragonFly platforms for a few months now. It's possible that the most current pkgsrc branch release, 2012Q3, is the first one where openJDK 7 works (maybe Q2, but I can't remember exactly when it was fixed). And you might get your wish on dedicated DragonFly ports... [teaser]
- TallGuyShort 14y ago
  I'm really sick of people ragging on the BSD's for their bad user experience. Dragonfly BSD has as its explicit goal to try develop ideas for a cluster operating system. Where did you get the idea that they were trying to deliver BSD on the desktop? Try PC BSD if that's what you want.

alberth 14y ago

How did the DragonFlyBSD team performance benchmark [1] against Postgres version 9.3 when the latest stable release is 9.2.1 and no development release of 9.3 is available? [1] http://lists.dragonflybsd.org/pipermail/users/attachments/20121010/7996ff88/attachment-0002.pdf http://lists.dragonflybsd.org/pipermail/users/attachments/20...

neverm0re 14y ago
Postgres 9.3-devel: http://www.postgresql.org/docs/devel/static/install-getsource.html http://www.postgresql.org/docs/devel/static/install-getsourc...
vsrinivas 14y ago
That these benchmarks were done with 9.3-devel was important; part of what triggered this work was PostGres moving to a different way of mapping it's shared memory segment (mmap vs shm), the benchmarks were initially done to see how much that hurt.

alberth 14y ago

In hindsight now, was Dillon correct in his approach to SMP & threading implementation over FreeBSD 5's approach?

vsrinivas 14y ago
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/ 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).