Page MenuHomeFreeBSD

intrng: switch from MAXCPU to mp_ncpus
ClosedPublic

Authored by ehem_freebsd_m5p.com on Aug 15 2023, 3:41 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Apr 14, 8:51 PM
Unknown Object (File)
Sun, Apr 14, 8:50 PM
Unknown Object (File)
Sun, Apr 14, 8:08 PM
Unknown Object (File)
Mar 10 2024, 2:37 PM
Unknown Object (File)
Jan 22 2024, 9:01 PM
Unknown Object (File)
Jan 20 2024, 1:37 AM
Unknown Object (File)
Jan 15 2024, 3:01 AM
Unknown Object (File)
Dec 25 2023, 1:41 AM
Subscribers

Details

Summary

MAXCPU could be on the large side, while the hardware may not have
many processors at all. As such only allocate counters for processors
which actually exist, rather than always allocating for the maximum
potentially allowed number.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

I believe CPU IDs are not guaranteed to be contiguous and mp_maxid is what should be used instead

In light of D41319 and the issues of what was observed when similar was done there. Presently this is untested, but I'm reasonably sure this is correct.

I'm not marking this as a parent of D41319 since there isn't a strict ordering requirement. Just D41319 may make the IPI counters become unpleasantly large overhead. Similar to the issues observed before D36838.

I believe CPU IDs are not guaranteed to be contiguous and mp_maxid is what should be used instead

I'm fairly sure they are on ARM and the other INTRNG platforms, but you could be right (reviewers, you know this better than I!). I'm not actually finding any documentation on what the differences between all the *mp_* variables are. I can roughly guess most of them, but the difference between mp_ncpus and smp_cpus isn't showing up.

Yes, I suspect that CPU IDs are contiguous on platforms which use intrng, but machine independent code should nonetheless use the range [0, mp_maxid] to index CPUs. See CPU_FOREACH(), for instance.

but the difference between mp_ncpus and smp_cpus isn't showing up.

mp_ncpus is the number of CPUs enumerated using platform-specific interfaces, smp_cpus is the number of CPUs that have been initialized and have started running kernel code. Once the kernel finishes booting, these two numbers are typically equal. There might be rare cases where they are not because one or more APs failed to initialize, and the kernel is limping along anyway.

The range is [0, mp_maxid], not [0, mp_maxid), so we should allocate mp_maxid + 1 counters.

Update to get things right. Though this is almost a fix on commit situation.

Errf, then find the goof after push.

This revision is now accepted and ready to land.Aug 31 2023, 5:55 PM
This comment was removed by emaste.
This revision was automatically updated to reflect the committed changes.