On Tue 2022-04-19 14:24:38, Luis Chamberlain wrote: > On Tue, Apr 19, 2022 at 01:56:03AM +0000, Edgecombe, Rick P wrote: > > Yea, that was my understanding. X86 modules have to be linked within > > 2GB of the kernel text, also eBPF x86 JIT generates code that expects > > to be within 2GB of the kernel text. > > And kprobes / live patching / ftrace. > > Another architectural fun fact, powerpc book3s/32 requires executability > to be set per 256 Mbytes segments. Some architectures like this one > will want to also optimize how they use the module alloc area. > > Even though today the use cases might be limited, we don't exactly know > how much memory a target device has a well, and so treating memory > failures for "special memory" request as regular memory failures seems > a bit odd, and users could get confused. For instance slapping on > extra memory on a system won't resolve any issues if the limit for a > special type of memory is already hit. Very likely not a problem at all today, > given how small modules / eBPF jit programs are / etc, but conceptually it > would seem wrong to just say -ENOMEM when in fact it's a special type of > required memory which cannot be allocated and the issue cannot possibly be > fixed. I don't think we have an option but to use -ENOMEM but at least > hinting of the special failure would have seem desirable. I am not mm expert but I think that this is common problem. There are many types of "special memory". And mm provides many details via procfs, e.g. /proc/meminfo, /proc/slabinfo, /proc/vmstat. Best Regards, Petr
