Increase MAX_APIC_ID safeguard to 0x800

[emaste]

Summary

0x200 is too low for systems with > 256 CPU threads.

[emaste]

AFAICT increasing this limit doesn't change anything for existing systems (we don't have any static-sized allocations based on MAX_APIC_ID, for instance).

[royger]

Could you do this in the same patch where MAXCPU is increased? I think it would be clearer that there's a dependency between MAXCPU and MAX_APIC_ID and that both need to be increased in lockstep.

Ideally it would be better if we could get rid of the arrays that are allocated based on max_apic_id and instead allocate them based on mp_ncpus, or else we just waste memory by allocating based on the sparse APIC ID space. We would then need to translate APIC ID into CPU ID. I realize I could have done the same when bumping to 256, so I don't blame you for not wanting to take on that task.

[emaste]

Could you do this in the same patch where MAXCPU is increased?

I'd like to do it independently, so that setting MAXCPU via the kernel config works again. Ideally also MFC this (but no MAXCPU bump) to stable/13. Alternatively, could we just replace MAX_APIC_ID with MAXCPU * 2?

Ideally it would be better if we could get rid of the arrays that are allocated based on max_apic_id ...

Yeah, we should. We have many of these sorts of things to fix on the path to bumping MAXCPU by default.

[royger]

In D37067#841727, @emaste wrote:

Could you do this in the same patch where MAXCPU is increased?

I'd like to do it independently, so that setting MAXCPU via the kernel config works again. Ideally also MFC this (but no MAXCPU bump) to stable/13. Alternatively, could we just replace MAX_APIC_ID with MAXCPU * 2?

I guess it could be sensible. I've kind of assumed than bumping MAXCPU over the default config was not meant to work flawlessly, and that the purpose of the option was to allow people to make it smaller for embedded deployments. If we really want to allow setting arbitrary MAXCPU values in config then we should fix the max_apic_id side.

Ideally it would be better if we could get rid of the arrays that are allocated based on max_apic_id ...

Yeah, we should. We have many of these sorts of things to fix on the path to bumping MAXCPU by default.

Hm, I see. I don't think it's a huge amount of work to purge the usage of max_apic_id for array allocations, but it needs someone to sit down and do the work.

[emaste]

It looks like MAX_APIC_ID is used only in madt_parse_cpu() as a limit, so this change should have no functional impact on any currently working system.
I agree that we should address allocations sized by max_apic_id; we need to do something similar for arrays sized by MAXCPU and that's going to be a lot more work.

[royger]

In D37067#843235, @emaste wrote:

It looks like MAX_APIC_ID is used only in madt_parse_cpu() as a limit, so this change should have no functional impact on any currently working system.
I agree that we should address allocations sized by max_apic_id; we need to do something similar for arrays sized by MAXCPU and that's going to be a lot more work.

Well, yes, MAXCPU sized array are also an issue, but at least memory is not wasted there. Not sure whether we have some tracking of technical debt, but this MAX_APIC_ID issue should definitely go there. It would even be fine for someone wanting to pick smaller stuff projects to do kernel development, as it's quite contained, and there's already arm64 code that does something similar with the Processor->UID space.