This is also the point which is the most likely to cause problems for this patch series (which is only fixes and utils added to the kernel) and the bcachefs in general.
Like when you have an entry like "bring back function which could make developing viruses easier (through not a vulnerability by themself) related to memory management and code execution" the default answer is nop .. nooop .. never. (Which doesn't mean that it won't come back).
It seems while it's not necessary to have this it's a non-neglible performance difference.
It would be really nice if he posted the difference with/without the optimisation for context. I hope it's going to be included in the explanation post he's planning.
It looks like the code generator is only available for x86 anyway, so it seems niche that way. I am all about baseline being good performance, not the special case.
It's bad enough that the kernel includes a JIT for eBPF. Adding more of them without hardware constraints and/or formal verification seems like a bad idea to me.
yeah, most of the kernel maintainers in that thread seem to be against it. bcachefs does seem to also have a non-code-generating implementation of this, as it runs on architectures other than x86-64.
Like when you have an entry like "bring back function which could make developing viruses easier (through not a vulnerability by themself) related to memory management and code execution" the default answer is nop .. nooop .. never. (Which doesn't mean that it won't come back).
It seems while it's not necessary to have this it's a non-neglible performance difference.