Sign up to save your podcasts
Or
Share Floating Point Problems | TechSNAP 396
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Floating Point Problems | TechSNAP 396
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.
Special Guest: Richard Yao.
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: kernelfpu{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 __kernelfpu{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.
View all episodes
By Jupiter BroadcastingJim 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.
Special Guest: Richard Yao.
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: kernelfpu{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 __kernelfpu{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.