Le 06/10/2022 à 20:22, Segher Boessenkool a écrit :

On Thu, Oct 06, 2022 at 11:39:50AM +1100, Michael Ellerman wrote:

quoted

Christophe Leroy [off-list ref] writes:

quoted

However, thinking out loudly, I'm wondering, could we make things any
simpler when CONFIG_MODULES is not selected, or is that a too much
corner case on PPC64 ?

I'd say it's mostly a corner case.

Obviously no distros ship with modules disabled.

AFAIK even the stripped down kernels we use in CPU bringup have modules
enabled.

So I think it's probably not worth worrying about, unless there's an
obvious and fairly simple optimisation.

Long ago I built kernels that fit together with the boot firmware and a
root fs (busybox+dropbear essentially) in 4MB, but I doubt we can get
close to that at all these days :-)

4MB, not easy. But 8M still achievable. Well our smaller board has 32M, 
we have thousands of it spread all over Europe and have to keep it up to 
date ....

What is the overhead if you enable modules but do not use them, these
days?

On the 8xx it is mainly the instruction TLB miss handler:

#ifdef CONFIG_MODULES
	mfcr	r11
	not.	r10, r10
#endif
	mfspr	r10, SPRN_M_TWB	/* Get level 1 table */
#ifdef CONFIG_MODULES
	blt+	3f
	rlwinm	r10, r10, 0, 20, 31
	oris	r10, r10, (swapper_pg_dir - PAGE_OFFSET)@ha
3:
	mtcr	r11
#endif


And also some patches which have a interesting impact, like commit 
cb3ac45214c0 ("powerpc/code-patching: Don't call 
is_vmalloc_or_module_addr() without CONFIG_MODULES")


On the other hand, if we want one day to replace nftables by BPF jitted 
iptables, CONFIG_MODULES will be required. So what will be the 
trade-off, don't know yet because BPF is not yet cross-compile friendly.

Christophe