Hi Jan,
On 2022/7/14 18:51, Jan Beulich wrote:
No matter how many separate "numa=" parameters have been parsed from
Command line, the values of these original variables are determined
after parsing the command line. So the determined status can be mapped
to the new one variable from above table.
Hmm, I was partly wrong - the initial values of both variables are
indeed set from just the single "numa=" parsing. But later on they
"evolve" independently, and multiple "numa=" on the command line
can also have "interesting" effects. I'm afraid I still can't
convince myself that the new mapping fully represents all originally
possible combinations (nor can I convince myself that in the existing
code everything is working as intended).
Maybe the solution is to make numa_off common but keep acpi_numa
arch-specific? Then e.g. the replacement of srat_disabled() could
be
int numa_disabled(void)
{
return numa_off || arch_numa_disabled();
}
with arch_numa_disabled() evaluating acpi_numa on x86.
While I am working on the new version, I think this may be not enough,
we may need another helper like arch_handle_numa_param to prevent direct
accessing of acpi_numa in numa_setup.
Cheers,
Wei Chen
Jan
