On 14.07.2022 12:37, Jan Beulich wrote:
> On 14.07.2022 12:26, Wei Chen wrote:
>>> From: Jan Beulich <jbeul...@suse.com>
>>> Sent: 2022年7月14日 17:58
>>> To: Wei Chen <wei.c...@arm.com>
>>>>
>>>> How about update the table like this:
>>>> +------------+----------+----------------+----------------+------------+
>>>> | original | | | | |
>>>> +------------+----------+----------------+----------------+------------+
>>>> | numa_off | true | true | true | true |
>>>> | acpi_numa | 0 | 1 | -1 | x |
>>>> | numa_fake | x | x | x | fake_nodes |
>>>> | enum state | numa_off | numa_off | numa_off | numa_off |
>>>> +------------+----------+----------------+----------------+------------+
>>>>
>>>> +------------+----------------+------------+-------------+------------+
>>>> | original | | | | |
>>>> +------------+----------------+------------+-------------+------------+
>>>> | numa_off | false | false | false | false |
>>>> | acpi_numa | 0 | 1 | -1 | x |
>>>> | numa_fake | x | x | x | fake_nodes |
>>>> | enum state | numa_fw_nodata | numa_fw_ok | numa_fw_bad | numa_emu |
>>>> +------------+----------------+------------+-------------+------------+
>>>
>>> Well, this makes the table complete, but it doesn't explain how you mean
>>> to fold the settings of the two command line options into one variable.
>>>
>>
>> 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.
Jan
