see this
https://www.phoronix.com/scan.php?page=news_item&px=Zstd-V8-For-Linux-Kernel-Comp
zstd is not in stable conf option ,
so this is in 5.9 , but that has been added in 5.8 rc time
in linux58-vd there is 2 patches for that
Comment compression_options and run mkinitcpio again.
Kernel comes with its own mkinitcpio preset file where zstd compression is set. This is to keep your selected comp algo for your other kernels.
Edit: I will update soon, including ProjectC scheduler and updates for the default config
Edit 2: update done, not tested. Default config is almost identical to Arch’s.
Edit 3: @jonathon, I think I fixed the remaining obvious bugs, you can go ahead.
Getting a checksum error on one patch file:
0003-init-kconfig-enable-O3.patch ... FAILED
Also minor warning:
---- Enter 'y' for nconfig:
/build/PKGBUILD: line 198: continue: only meaningful in a `for', `while', or `until' loop
Oops. Forgot to update. EDIT: remember to clean your $srcdir, I pushed an update.
You can ignore the warning, I’m aware of it, improper use of continue.
Hmm. Building in a Docker build container on a Ryzen 2700X host ends up with:
GEN .version
CHK include/generated/compile.h
LD vmlinux.o
MODPOST vmlinux.symvers
MODINFO modules.builtin.modinfo
GEN modules.builtin
BTF: .tmp_vmlinux.btf: pahole (pahole) is not available
Failed to generate BTF for vmlinux
Try to disable CONFIG_DEBUG_INFO_BTF
make: *** [Makefile:1140: vmlinux] Error 1
I’ll try building locally.
Edit: Hm, that killed my laptop. Maybe ran out of RAM (though I have 32GB+40GB swap…).
Oh… I’ve never used Docker containers so I don’t know. Not sure if it is directly related to Docker, the other 2 config files don’t have that option set.
The error message tells us to disable CONFIG_DEBUG_INFO_BTF, would be great if you could check this.
(sed -i 's/INFO\_BTF\=y/INFO\_BTF\=n/g' config.x86_64)
See 
No I don’t think that’s RAM. You should be able to build this with 4G of RAM 
Temperatures maybe, given the heatwave over parts of Europe?
My Ryzen hit 85°C+ yesterday…
Half OT: have you tried systemd containers yet? Pretty neat systemd feature if you ask me…
EDIT: sudo pacman -S pahole maybe?
Possibly. It was ~7pm local so it wasn’t too warm, though the laptop doesn’t have the best cooling setup.
Testing this now. If it works, does that make pahole a makedepend ?
Edit, worked. Let’s see how it installs and runs. 
I have now set DEBUG_INFO_BTF=n, maybe this is already sufficient to fix that problem?
I’ll try another clean-chroot compile.
This one didn’t want to mount my ZFS pools with my 5.8-patched zfs-dkms so I’m back to linux-ck-zen=5.7.15 for now…
(Also,
0003-init-kconfig-enable-O3.patch ... FAILED
with a cleaned SRCDEST.)
Hmm what you could try is building zfs as extramodule, similar to Manjaro.
I haven’t tested this for a long time.
That damn file - no idea what happens there. I constantly get “failed” there and have to update again…
EDIT: Let me try to build the zfs extramodule… unfortunately I’m on clang kernel, always a bit tricky
Might be because it’s coming from the master branch rather than a specific commit?
0003-init-kconfig-enable-O3.patch::https://raw.githubusercontent.com/sirlucjan/kernel-patches/master/5.8-rc/cpu-patches-v3-sep/0002-init-Kconfig-enable-O3-for-all-arches.patch
Good catch, it’s still using 5.8-rc.
I guess I just simply include the file without the URL.
@jonathon, I’ve just successfully built zfs extramodule. I don’t know if it works, but the build process finished without errors.
I’ll push the update in a few minutes.
Try systemd containers 
easy to set up, easy to manage: https://wiki.archlinux.org/index.php/Systemd-nspawn
Yeah, the DKMS module builds for me, it just sat at “Importing ZFS pools” for a few minutes (it should only take a few seconds, so I gave up waiting).
My office/build PC has Docker on it, so that’s what I’m using… 
Did you try with the patch that Manjaro uses? https://gitlab.manjaro.org/packages/extra/linux58-extramodules/spl_zfs/-/blob/master/Linux-5.8-compat-__vmalloc.patch
Sorry, not a ZFS expert here 
That’s the patch I imported/backported from ZFS upstream, so yes. 
I’m an edge-case, though, so don’t worry too much. I’ll also test with Arch or mainline 5.8 at some point.
Edit: 5.8.1-2 built without any extra BDs.
I’m currently investigating the use of THP (transparent hugepages) and its impact on performance. Maybe I’ll do like you and create a little FAQ.
Although there are better ways to measure it (perf!), here are some (inconclusive) results:
thp = always, defrag = defer+madvise:
stress-ng cpu: 157.85
stress-ng memory: 96.48
perf sched: 55.011
perf memcpy: 22.88
calculating 60m digits of pi: 58.53
argon2 hashing: 31.95
ffmpeg compilation: 248.14
xz compression: 320.22
Blender render: 961.02
thp = never, defrag = never:
stress-ng cpu: 156.65
stress-ng memory: 96.81
perf sched: 55.268
perf memcpy: 9.87
calculating 60m digits of pi: 59.24
argon2 hashing: 33.19
ffmpeg compilation: 248.69
xz compression: 334.92
Blender render: 980.08
Hopefully, more info soon. The results look pretty interesting to me.
Issues with ZFS were on my end, apparently. Same thing waiting for pools to import with 5.8.1-arch1-1 so I booted into single-user mode, imported the pool manually, rebooted, and it was fine from then on. No idea… 
Just wondering, how does performance compare to the “gaming” kernels like xanmod and tkg ?
Oh, i had no idea tkg has Kernel 