On Fri, Oct 1, 2021 at 9:51 AM Will McVicker [off-list ref] wrote:

On Fri, Oct 1, 2021 at 9:00 AM Olof Johansson [off-list ref] wrote:

quoted

On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven [off-list ref] wrote:

quoted

Hi Olof,

On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson [off-list ref] wrote:

quoted

A much more valuable approach would be to work towards being able to
free up memory by un-probed drivers at the end of boot. That would
possibly benefit all platforms on all architectures.

We used to have such a functionality in arch/ppc (not arch/powerpc!),
where code/data could be tagged __prep, __chrp, or __pmac, to put it
in a special section, and to be freed with initdata when unused.  It
was removed in v2.6.15[1], as the savings weren't worth the hassle.
In a more fragmented space like arm the memory lost due to alignment
of the sections would be even more substantial.

Yeah, the balance between per-platform code size and overall kernel
code size shifted over time to a point where it wasn't as meaningful
on ppc.

quoted

Another problem is to know when is the end of the boot, especially
with deferred probing.

Most of this code either has a module_init() or an initcall that
actually registers the drivers and/or probes for the platform and does
the work.

This means you can have a late equivalent hook/initcall that
determines whether this path ended up being probed/used. If it wasn't,
you can then unregister and flag the corresponding memory to be freed
at the end, and would take out the heuristics and guessing on needing
to do it automatically from the code path that's doing said freeing.


-Olof

First off, I appreciate the constructive conversations and I
understand the ask here. So I'd like to close the "we don't want this"
and "this isn't possible" conversation. We have already proven
downstream that it is in fact possible to modularize these drivers on
other SoCs (mentioned earlier if you missed it) and I'd like to direct
the conversation towards verifying/testing here instead of negatively
arguing about how SoC vendors aren't upstreaming their drivers. I
think everyone understands that, but unfortunately I have no control
over that even though I would love everyone to work upstream directly.

I am fine with forcing these drivers to always be enabled in some form
upstream even though it doesn't really make much sense for a generic
kernel that will run on Qualcomm, Exynos, Mediatek, (you name it) SoC
devices. I thought about how to do this yesterday and wasn't able to
come up with a proper solution that didn't always force this driver to
be a module when CONFIG_MODULES is enabled.

This line of reasoning: "I couldn't think of a better option" made us
merge a userspace ABI some time ago that within a few months was
replaced with a better solution. In that case it was the kernel
headers bundling with a build (extending the vmlinux size by a lot),
that seemed to have no concerns about binary growth. Not all that far
after that went in, the BPF folks came up with a solid solution for
CO-RE by introducing BTF, etc.

So, the argument "I can't think of a better solution" is a local
maxima that we shouldn't settle for if there's a likely better global
maxima available with a bit more time/effort. If we say "this problem
is worth solving but this doesn't seem to be the solution we want to
go for" we might actually be better off long-term.


-Olof