On Tue, 2022-11-08 at 13:27 +0200, Mike Rapoport wrote: > > Based on our experiments [5], we measured 0.5% performance > > improvement > > from bpf_prog_pack. This patchset further boosts the improvement to > > 0.7%. > > The difference is because bpf_prog_pack uses 512x 4kB pages instead > > of > > 1x 2MB page, bpf_prog_pack as-is doesn't resolve #2 above. > > > > This patchset replaces bpf_prog_pack with a better API and makes it > > available for other dynamic kernel text, such as modules, ftrace, > > kprobe. > > > The proposed execmem_alloc() looks to me very much tailored for x86 > to be > used as a replacement for module_alloc(). Some architectures have > module_alloc() that is quite different from the default or x86 > version, so > I'd expect at least some explanation how modules etc can use execmem_ > APIs > without breaking !x86 architectures. I think this is fair, but I think we should ask ask ourselves - how much should we do in one step? For non-text_poke() architectures, the way you can make it work is have the API look like: execmem_alloc() <- Does the allocation, but necessarily usable yet execmem_write() <- Loads the mapping, doesn't work after finish() execmem_finish() <- Makes the mapping live (loaded, executable, ready) So for text_poke(): execmem_alloc() <- reserves the mapping execmem_write() <- text_pokes() to the mapping execmem_finish() <- does nothing And non-text_poke(): execmem_alloc() <- Allocates a regular RW vmalloc allocation execmem_write() <- Writes normally to it execmem_finish() <- does set_memory_ro()/set_memory_x() on it Non-text_poke() only gets the benefits of centralized logic, but the interface works for both. This is pretty much what the perm_alloc() RFC did to make it work with other arch's and modules. But to fit with the existing modules code (which is actually spread all over) and also handle RO sections, it also needed some additional bells and whistles. So the question I'm trying to ask is, how much should we target for the next step? I first thought that this functionality was so intertwined, it would be too hard to do iteratively. So if we want to try iteratively, I'm ok if it doesn't solve everything.
