Announcement

Collapse
No announcement yet.

DragonFlyBSD's Kernel Optimizations Are Paying Off - 3 BSDs & 5 Linux OS Benchmarks On Threadripper

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • DragonFlyBSD's Kernel Optimizations Are Paying Off - 3 BSDs & 5 Linux OS Benchmarks On Threadripper

    Phoronix: DragonFlyBSD's Kernel Optimizations Are Paying Off - 3 BSDs & 5 Linux OS Benchmarks On Threadripper

    DragonFlyBSD lead developer Matthew Dillon has been working on a big VM rework in the name of performance and other kernel improvements recently. Here is a look at how those DragonFlyBSD 5.5-DEVELOPMENT improvements are paying off compared to DragonFlyBSD 5.4 as well as FreeBSD 12 and five Linux distribution releases. With Dillon using an AMD Ryzen Threadripper system, we used that too for this round of BSD vs. Linux performance benchmarks.

    http://www.phoronix.com/vr.php?view=27932

  • dillon
    replied
    Not bad... mostly what I expected. In particular, that slight regression in pgbench... I saw that in my own testing but what might not be apparent is that the scheduler heuristics were actually broken for a long time in 5.4 and resulted in horrendous pgbench numbers (half of what they were before). When I fixed it relatively recently in 5.5, I still couldn't get back to the original numbers, though I was able to get very close. pgbench is extremely sensitive to scheduler heuristics. If each client and the server pair (for same-machine client and server)... if the client and server are not scheduled to the same CCX a lot of performance is lost. Under medium loads if the client and server are not scheduled to sibling hyper-thread pairs, performance is lost. Then, under the heaviest loads (say, 128 client / 128 server), if the client and server are not scheduled to the same logical cpu, performance is lost. In the latter case, because under extreme loads being able to avoid the sleep/wakeup IPIs becomes extremely important.

    The OpenMP stuff has always had problems on the BSDs. I believe this issue comes down to how individual page protections are handled. In Linux, if I understand the code properly, they are just flipping protection bits in the terminal PTEs and thus overhead for sporatic page protection strewn around the shared memory is low. On the BSDs, including DragonFly, mprotect() calls have a certain degree of kernel structural overhead in the vm_map/vm_map_entry handling code that makes sparse/sporatic page protection more expensive. At least we were able to remove the 'struct pv_entry' overhead in the kernel which was per-PTE, though.

    The JAVA benches tend to be determined by the memory allocator in libc. We did testing a few years ago and basically if we cached enormous amounts of memory we could get good scores (this is why FreeBSD does fairly well, and I believe also why linux does very well)... but there is a huge cost to doing that because an enormous amount of memory winds up being wasted. If you happen to be running a java workload that needs a lot of memory, or it is sharing resources with other applications running on the machine, the whole thing can bog down and implode. So we opted to cache less free memory in libc (though we have opened it up a bit in the last year).

    The compiler benches seem kinda ridiculous since the same compiler configuration is not being compared. There are trade-offs there too... different projects choose defaults to focus on different levels of safety and robustness. So there isn't much of a point benching the differences. Similarly, benching predominantly user-space code is not really an operating system test, just a test of the default 'cc'. And sometimes those bench programs get hung up in linux-specific optimizations (literally #ifdef'd code) that makes them unreasonable on other platforms. Care must be taken.

    -Matt

    Leave a comment:


  • Bsdisbetter
    replied
    Originally posted by stormcrow View Post


    No I haven't missed the point of HardenedBSD at all. In fact I purposely pointed out why it exists, which you apparently ignored. I simply disagree with FreeBSD's problematic stance on conservative compatibility at the expense of the security of the entire platform.
    I didn't ignore it, I specifically addressed it: 'innovative' security.

    By your statement, I take it you take exception to EVERY linux distro then?

    The statement remains true: freebsd chose not to be aggressive/innovative like the way hardenedbsd wanted, so they forked. Disagree all you want it doesn't change the fact they are correct and you are wrong. Why should freebsd, the basis for many other releases suddenly become the radical innovator two developers want? Are you crazy?
    Of course the implication that somehow freebsd is insecure because it doesn't adopt hardenedbsd's mantra is equally specious.
    Last edited by Bsdisbetter; 06-01-2019, 07:48 PM.

    Leave a comment:


  • brad0
    replied
    Originally posted by stormcrow View Post
    I simply disagree with FreeBSD's problematic stance on conservative compatibility at the expense of the security of the entire platform.
    Linux is in the same boat but it's even worse.

    Leave a comment:


  • stormcrow
    replied
    Originally posted by Bsdisbetter View Post

    You seem to totally miss the point of hardenedbsd. It's a fork so they can 'be innovative' (their words) with security. Freebsd is very conservative so doing this in freebsd's kernel is a no-go. Once valid code is proven it likely makes it into freebsd in a future release.

    No I haven't missed the point of HardenedBSD at all. In fact I purposely pointed out why it exists, which you apparently ignored. I simply disagree with FreeBSD's problematic stance on conservative compatibility at the expense of the security of the entire platform.

    Leave a comment:


  • Bsdisbetter
    replied
    Originally posted by stormcrow View Post
    I guess I'm strange, but from my point of view reading through the benchmark scores the comment came to mind, not that Dragonfly BSD had a big improvement in upcoming 5.5, but that ye old basic (boring?) FreeBSD 12 performance "didn't suck" any more compared to Linux for many of those tests. Solid performance numbers there.

    Now if only FreeBSD would get on the ball with getting serious about security and having it not take a back seat to 20 year old compatibility knobs... (which is why HardenedBSD exists).
    You seem to totally miss the point of hardenedbsd. It's a fork so they can 'be innovative' (their words) with security. Freebsd is very conservative so doing this in freebsd's kernel is a no-go. Once valid code is proven it likely makes it into freebsd in a future release.

    Leave a comment:


  • Volta
    replied
    Originally posted by stormcrow View Post
    old basic (boring?) FreeBSD 12 performance "didn't suck" any more compared to Linux for many of those tests. Solid performance numbers there.
    It seems they did a good thing by moving to clang. It may also depend on tests selection. What's funny it sucks in bsd licensed postgreSQL.

    Leave a comment:


  • aht0
    replied
    Wonder what particular variant of FreeBSD12 was used in test.

    In mid-April, jump from Clang 6.0 to Clang 8.0 happened. 12-RELEASE came out using Clang 6 for system compiler but 12-STABLE has been using Clang 8.0 now. I imagine both perform quite differently.

    Leave a comment:


  • Grinch
    replied
    Some of these tests results are just impossible to believe outside of a major configuration misshap, that x265 which is extremely cpu bound and heavily assembly optimized would be ~30% faster on FreeBSD compared to Ubuntu 19.04 just makes zero sense.

    Leave a comment:


  • stormcrow
    replied
    I guess I'm strange, but from my point of view reading through the benchmark scores the comment came to mind, not that Dragonfly BSD had a big improvement in upcoming 5.5, but that ye old basic (boring?) FreeBSD 12 performance "didn't suck" any more compared to Linux for many of those tests. Solid performance numbers there.

    Now if only FreeBSD would get on the ball with getting serious about security and having it not take a back seat to 20 year old compatibility knobs... (which is why HardenedBSD exists).

    Leave a comment:

Working...
X