On Mon, Jun 19, 2023 at 06:47:17AM -0400, Kent Overstreet wrote: > On Mon, Jun 19, 2023 at 10:19:00AM +0100, Mark Rutland wrote: > > On Tue, May 09, 2023 at 12:56:32PM -0400, Kent Overstreet wrote: > > > From: Kent Overstreet <kent.overstreet@xxxxxxxxx> > > > > > > This is needed for bcachefs, which dynamically generates per-btree node > > > unpack functions. > > > > Much like Kees and Andy, I have concerns with adding new code generators to the > > kernel. Even ignoring the actual code generation, there are a bunch of subtle > > ordering/maintenance/synchronization concerns across architectures, and we > > already have a fair amount of pain with the existing cases. > > Look, jits are just not that unusual. I'm not going to be responding to > vague concerns that don't have any actual engineering rational. Sorry, but I do have an engineering rationale here: I want to make sure that this actually works, on architectures that I care about, and will be maintanable long-term. We've had a bunch of problems with other JITs ranging from JIT-local "we got the encoding wrong" to major kernel infrastructure changes like tasks RCU rude synchronization. I'm trying to figure out whether any of those are likely to apply and/or whether we should be refactoring other infrastructure for use here (e.g. the factoring the acutal instruction generation from arch code, or perhaps reusing eBPF so this can be arch-neutral). I appreciate that's not clear from my initial mail, but please don't jump straight to assuming I'm adversarial here. > > Can you share more detail on how you want to use this? > > > > From a quick scan of your gitweb for the bcachefs-for-upstream branch I > > couldn't spot the relevant patches. > > I've already written extensively in this thread. Sorry, I hadn't seen that. For the benefit of others, the codegen is at: https://lore.kernel.org/lkml/ZFq7JhrhyrMTNfd%2F@xxxxxxxxxxxxxx/ https://evilpiepirate.org/git/bcachefs.git/tree/fs/bcachefs/bkey.c#n727 ... and the rationale is at: https://lore.kernel.org/lkml/ZF6HHRDeUWLNtuL7@xxxxxxxxxxxxxx/ One thing I note mmediately is that HAVE_BCACHEFS_COMPILED_UNPACK seems to be x86-only. If this is important, that'll need some rework to either be arch-neutral or allow for arch-specific implementations. Thanks, Mark.
