Page MenuHomeFreeBSD

x86: Scale default msi/msix vector limit with MAXCPU
Needs ReviewPublic

Authored by cem on Jun 12 2020, 9:29 PM.



Rather than hardcoding another number, scale the default MSI vector limit with

No functional change for amd64 (from 2048 @ r362112). On i386, this reduces
the number of default MSI vectors to 256 (from 512 @ r362111).

Test Plan

This doesn't scale well at the lower limit (especially the extreme case, !SMP),
but I think it is acceptable for current default MAXCPU on x86. (I don't think
SMP && x86 makes much sense as a build configuration anymore; we keep !SMP
mostly for extremely embedded systems like ARM and MIPS.)

Diff Detail

rS FreeBSD src repository
Lint OK
No Unit Test Coverage
Build Status
Buildable 31671
Build 29249: arc lint + arc unit

Event Timeline

cem created this revision.Jun 12 2020, 9:29 PM
cem requested review of this revision.Jun 12 2020, 9:29 PM
kib added inline comments.Jun 23 2020, 3:38 AM

I suggest you to either use eg. (MAXCPU + 20) * 8 (20 came just from the air), or 128 + MAXCPU * 8 (128 came from the same source). This should solve UP issues.

People are using VMs with single CPU.

jhb added inline comments.Jun 24 2020, 4:46 PM

And maybe use MIN() or the like to enforce at least 512? The theoretical upper limit is something like 200 * MAXCPU (more like 190 or 191 per CPU IIRC). The cost for this value being too high is fairly small (a single array of pointers adds 1 more pointer for each value)s, so erring on the side of too high is probably ok. You could also make this a runtime calculation based off of mp_ncpus if you wanted if you had a default of 0 and then used a SYSINIT to compute the value if it was still zero (if you are truly ambitious). I think scaling with MAXCPU is probably fine though.