Page MenuHomeFreeBSD

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

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

Details

Reviewers
jhb
gallatin
kib
Summary

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

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

Repository
rS FreeBSD src repository
Lint
Lint OK
Unit
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
sys/x86/x86/msi.c
159

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
sys/x86/x86/msi.c
159

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.