|
Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1, v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2, v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3, v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2, v5.4.1, v5.4.0, v5.5.0, v5.4.0rc1, v5.2.2, v5.2.1, v5.2.0, v5.3.0, v5.2.0rc, v5.0.2, v5.0.1, v5.0.0, v5.0.0rc2, v5.1.0, v5.0.0rc1, v4.8.1 |
|
| #
70f74b76 |
| 07-Apr-2017 |
Matthew Dillon <dillon@apollo.backplane.com> |
Revert "kernel - Spread IPIs out to more priority levels"
This commit seems to be causing a performance regression on VMs.
Since it didn't fix a particular bug (was just supposed to make
things more
Revert "kernel - Spread IPIs out to more priority levels"
This commit seems to be causing a performance regression on VMs.
Since it didn't fix a particular bug (was just supposed to make
things more robust), revert it for now.
Reported-by: tkusumi
This reverts commit f240042b9f9bcfdacd70499659fcc5f55d5e49ab.
show more ...
|
| #
f240042b |
| 27-Mar-2017 |
Matthew Dillon <dillon@apollo.backplane.com> |
kernel - Spread IPIs out to more priority levels
* Due to the brandamaged way the LAPIC queues received IPIs, each
priority level (the top 4 bits of the 8 bit vector) has a 2-entry
FIFO. Bring
kernel - Spread IPIs out to more priority levels
* Due to the brandamaged way the LAPIC queues received IPIs, each
priority level (the top 4 bits of the 8 bit vector) has a 2-entry
FIFO. Bring in comments from FreeBSD on how this works.
* Change our IPI vectors which previously used 2 priority levels to now
use 3 priority levels. Each source is generally limited by an atomic
op to avoid multi-queueing and hopefully that means the above LAPIC hw
queue will never refuse to accept an IPI.
IPIQ and TIMER use group 1
INVLTLB (and INVLPG) uses group 2
SNIFF, CPUSTOP, and SPURIOUSINT use group 3
* Reduces the number of vectors available per cpu by 16, but shouldn't
present that big a problem.
show more ...
|
|
Revision tags: v4.8.0, v4.6.2, v4.9.0, v4.8.0rc, v4.6.1, v4.6.0, v4.6.0rc2, v4.6.0rc, v4.7.0 |
|
| #
e3c41896 |
| 13-Jun-2016 |
Sepherosa Ziehau <sephe@dragonflybsd.org> |
hyperv/vmbus: Complete vmbus initialization; interrupt cputimer is enabled
Most of the bits are obtained from FreeBSD. However, The interrupt bits
are reworked:
- Since the vmbus message/event inte
hyperv/vmbus: Complete vmbus initialization; interrupt cputimer is enabled
Most of the bits are obtained from FreeBSD. However, The interrupt bits
are reworked:
- Since the vmbus message/event interrupt works in the same fashion as
MSI-X, we just allocate MSI-X for them, instead of allocating IDT
vector, rolling vmbus own interrupt vector and turning the interrupt
handling inside-out. The standard and generic bus APIs are used to
allocate and setup per-cpu vmbus interrupt.
- Interrupt cputimer reuses the current per-cpu interrupt timer code.
- AutoEOI is not used, since we reuse the per-cpu interrupt timer IDT
vector and MSI IDT vector. After a brief discussion w/ Dexuan Cui,
I concluded that AutoEOI probably does not provide noticible performance
improvement but will introduce extra code complexity. We leave it off
for now.
Obtained-from: FreeBSD (mostly)
show more ...
|
|
Revision tags: v4.4.3, v4.4.2, v4.4.1, v4.4.0, v4.5.0, v4.4.0rc, v4.2.4, v4.3.1, v4.2.3, v4.2.1, v4.2.0, v4.0.6, v4.3.0, v4.2.0rc, v4.0.5, v4.0.4, v4.0.3, v4.0.2, v4.0.1, v4.0.0, v4.0.0rc3, v4.0.0rc2, v4.0.0rc, v4.1.0, v3.8.2, v3.8.1, v3.6.3, v3.8.0, v3.8.0rc2, v3.9.0, v3.8.0rc, v3.6.2, v3.6.1, v3.6.0, v3.7.1, v3.6.0rc, v3.7.0, v3.4.3, v3.4.2, v3.4.0, v3.4.1, v3.4.0rc, v3.5.0, v3.2.2, v3.2.1, v3.2.0, v3.3.0, v3.0.3, v3.0.2, v3.0.1, v3.1.0, v3.0.0 |
|
| #
c9852c4c |
| 25-Dec-2011 |
Sepherosa Ziehau <sephe@dragonflybsd.org> |
msi: Add setup/map function
- msi_setup, setup the IDT entry properly
- msi_map, return the MSI address and MSI data according to the
'intr' and 'cpuid'
The various MSI macros forming MSI address
msi: Add setup/map function
- msi_setup, setup the IDT entry properly
- msi_map, return the MSI address and MSI data according to the
'intr' and 'cpuid'
The various MSI macros forming MSI address/data are taken from FreeBSD
show more ...
|