![[BACK]](/icons/back.gif){kind=icon}
Up to [local] / src / sys / sys
Request diff between arbitrary revisions
Default branch: MAIN
Revision 1.3 / (download) - annotate - [select for diffs], Tue Jun 23 01:40:03 2020 UTC (3 years, 11 months ago) by dlg
Branch: MAIN
CVS Tags: OPENBSD_7_5_BASE,
OPENBSD_7_5,
OPENBSD_7_4_BASE,
OPENBSD_7_4,
OPENBSD_7_3_BASE,
OPENBSD_7_3,
OPENBSD_7_2_BASE,
OPENBSD_7_2,
OPENBSD_7_1_BASE,
OPENBSD_7_1,
OPENBSD_7_0_BASE,
OPENBSD_7_0,
OPENBSD_6_9_BASE,
OPENBSD_6_9,
OPENBSD_6_8_BASE,
OPENBSD_6_8,
HEAD
Changes since 1.2: +2 -1 lines
Diff to previous 1.2 (colored)
add intrmap_one, some temp code to help us write pci_intr_establish_cpu. it means we can do quick hacks to existing drivers to test interrupts on multiple cpus. emphasis on quick and hacks. ok jmatthew@, who will also ok the removal of it at the right time.
Revision 1.2 / (download) - annotate - [select for diffs], Wed Jun 17 03:01:26 2020 UTC (3 years, 11 months ago) by dlg
Branch: MAIN
Changes since 1.1: +2 -2 lines
Diff to previous 1.1 (colored)
make intrmap_cpu return a struct cpu_info *, not a "cpuid number" thing. requested by kettenis@ discussed with jmatthew@
Revision 1.1 / (download) - annotate - [select for diffs], Wed Jun 17 00:27:52 2020 UTC (3 years, 11 months ago) by dlg
Branch: MAIN
add intrmap, an api that picks cpus for devices to attach interrupts to. there's been discussions for years (and even some diffs!) about how we should let drivers establish interrupts on multiple cpus. the simple approach is to let every driver look at the number of cpus in a box and just pin an interrupt on it, which is what pretty much everyone else started with, but we have never seemed to get past bikeshedding about. from what i can tell, the principal objections to this are: 1. interrupts will tend to land on low numbered cpus. ie, if drivers try to establish n interrupts on m cpus, they'll start at cpu 0 and go to cpu n, which means cpu 0 will end up with more interrupts than cpu m-1. 2. some cpus shouldn't be used for interrupts. why a cpu should or shouldn't be used for interrupts can be pretty arbitrary, but in practical terms i'm going to borrow from the scheduler and say that we shouldn't run work on hyperthreads. 3. making all the drivers make the same decisions about the above is a lot of maintenance overhead. either we will have a bunch of inconsistencies, or we'll have a lot of untested commits to keep everything the same. my proposed solution to the above is this diff to provide the intrmap api. drivers that want to establish multiple interrupts ask the api for a set of cpus it can use, and the api considers the above issues when generating a set of cpus for the driver to use. drivers then establish interrupts on cpus with the info provided by the map. it is based on the if_ringmap api in dragonflybsd, but generalised so it could be used by something like nvme(4) in the future. this version provides numeric ids for CPUs to drivers, but as kettenis@ has been pointing out for a very long time, it makes more sense to use cpu_info pointers. i'll be updating the code to address that shortly. discussed with deraadt@ and jmatthew@ ok claudio@ patrick@ kettenis@