Episode 396

Floating Point Problems

Download Subscribe
00:00:00
/
00:27:11
RSS Feed Download (18.7 MB) Link with Timestamp

January 31st, 2019

27 mins 11 secs

Link with Timestamp

Download MP3 (18.7 MB)

Your Hosts
Special Guest
Tags
vectorized instructions avx techsnap devops sysadmin podcast zvol raid storage zfs on linux zol zfs openzfs kernel preemption multitasking linux software license header kernel module freebsd clone snapshot checksum floating point lfnw data integrity journaling hardware acceleration simd fpu oracle cddl gpl

About this Episode

Jim and Wes are joined by OpenZFS developer Richard Yao to explain why the recent drama over Linux kernel 5.0 is no big deal, and how his fix for the underlying issue might actually make things faster.

Plus the nitty-gritty details of vectorized optimizations and kernel preemption, and our thoughts on the future of the relationship between ZFS and Linux.

Episode Links

  • LinuxFest Northwest 2019 — Join a bunch of JB hosts and community celebrating the 20th anniversary!
  • Choose Linux — The show that captures the excitement of discovering Linux.
  • Linux 5.0: _kernel_fpu{begin,end} no longer exported — The latest kernels removed the old compatibility headers.
  • ZFS On Linux Landing Workaround For Linux 5.0 Kernel Support — So while these symbols are important for SIMD vectorized checksums for ZFS in the name of performance, with Linux 5.0+ they are not going to be exported for use by non-GPL modules. ZFS On Linux developer Tony Hutter has now staged a change that would disable vector instructions on Linux 5.0+ kernels.
  • Re: x86/fpu: Don't export __kernel_fpu_{begin,end}() — My tolerance for ZFS is pretty non-existant. Sun explicitly did not want their code to work on Linux, so why would we do extra work to get their code to work properly?
  • The future of ZFS in FreeBSD — This state of affairs has led to a general agreement among the stakeholders that I have spoken to that it makes sense to rebase FreeBSD's ZFS on ZoL. Brian Behlendorf has graciously encouraged me to add FreeBSD support directly so that we might all have a singleshared code base.
  • Dephix: Kickoff to The Future — OpenZFS has grown over the last decade, and delivering our application on Linux provides great OpenZFS support while enabling higher velocity adoption of new environments.
  • The future of ZFS on Linux [zfs-discuss] — Do you realize that we don’t actually need the symbols that the kernel removed. It All they do is save/restore of register state while turning off/on preemption. Nothing stops us from doing that ourselves. It is possible to implement our own substitutes using code from either Illumos or FreeBSD or even write our own. Honestly, I am beginning to think that my attempt to compromise with mainline gave the wrong impression. I am simply tired of this behavior by them and felt like reaching out to put an end to it. In a few weeks, we will likely be running on Linux 5.0 as if those symbols had never been removed because we will almost certainly have our own substitutes for them. Having to bloat our code because mainline won’t give us access to trivial functionality is annoying, but it is not the end of the world.
  • LINUX Unplugged Episode 284: Free as in Get Out
  • BSD Now 279: Future of ZFS
  • BSD Now 157: ZFS, The “Universal” File-system