With MAXCPU being 1024 on amd64 and arm64, the number of allocated task
slots (4096) looks too high for any practical use (barring bugs filling
all slots, in which case the actual limit does not matter). For
example, on a 24-CPU machine with a long uptime,
'debug.acpi.tasks_hiwater' is only 23.
We do not seem to have received a lot of complaints by people getting
"AcpiOsExecute: failed to enqueue task, consider increasing the
debug.acpi.max_tasks tunable". There is such report in PR 282241 but as
symptom of another problem that was fixed. Such an error is mentioned
in PR 160838, which references a bump of ACPI_MAX_TASKS fixing it
(scaling from 2 * MAXCPU to 4 * MAXCPU), and in PR 176591 (of before the
last ACPI_MAX_TASKS bump), the MAXCPU bump from 64 to 256 having
intervened some years after the reports, in 2014 (and the last bump to
1024 in 2023). It also appears in a trace in the old PR 144956 (MAXCPU
was only 32 back then, as well as ACPI_MAX_TASKS).
So, scale ACPI_MAX_TASKS with the actual number of CPUs rather than
MAXCPU, as this has probably been intended from the start, keeping the
same 4 factor but providing some more breathing room for machines with
a low number of CPUs by adding a fixed amount of 64. The old value of
4096 slots is now reached only on machines with 1008 cores, and typical
16 CPUs machines only allocate 128 slots.
In acpi_task_enqueue() when no task slot is available, suggest in the
diagnostic message to report the value of 'debug.acpi.tasks_hiwater'
after having raised 'debug.acpi.max_tasks'.
While here, sort the headers in 'acpivar.h'.