| #
5d12db2d
|
| 22-Nov-2024 |
Mark Johnston <markj@FreeBSD.org> |
dtrace: Avoid excessive pcpu allocations
We were previously allocating MAXCPU structures for several purposes, but this is generally unnecessary and is quite excessive, especially after MAXCPU was b
dtrace: Avoid excessive pcpu allocations
We were previously allocating MAXCPU structures for several purposes, but this is generally unnecessary and is quite excessive, especially after MAXCPU was bumped to 1024 on amd64 and arm64. We already are careful to allocate only as many per-CPU tracing buffers as are needed; extend this to other allocations.
For example, in a 2-vCPU VM, the size of a consumer state structure drops from 64KB to 128B. The size of the per-consumer `dts_buffer` and `dts_aggbuffer` arrays shrink similarly. Ditto for pre-allocations of local and global D variable storage space.
MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D47667
show more ...
|
| #
95ee2897
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
| #
66b8eced
|
| 08-Aug-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
dtrace: use %zu format specifier for data of size_t type
Sponsored by: The FreeBSD Foundation
|
| #
5d12db2d
|
| 22-Nov-2024 |
Mark Johnston <markj@FreeBSD.org> |
dtrace: Avoid excessive pcpu allocations
We were previously allocating MAXCPU structures for several purposes, but this is generally unnecessary and is quite excessive, especially after MAXCPU was b
dtrace: Avoid excessive pcpu allocations
We were previously allocating MAXCPU structures for several purposes, but this is generally unnecessary and is quite excessive, especially after MAXCPU was bumped to 1024 on amd64 and arm64. We already are careful to allocate only as many per-CPU tracing buffers as are needed; extend this to other allocations.
For example, in a 2-vCPU VM, the size of a consumer state structure drops from 64KB to 128B. The size of the per-consumer `dts_buffer` and `dts_aggbuffer` arrays shrink similarly. Ditto for pre-allocations of local and global D variable storage space.
MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D47667
show more ...
|
| #
95ee2897
|
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
| #
66b8eced
|
| 08-Aug-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
dtrace: use %zu format specifier for data of size_t type
Sponsored by: The FreeBSD Foundation
|
| #
be27b311
|
| 04-May-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r317503 through r317807.
|
| #
23bff607
|
| 01-May-2017 |
Mark Johnston <markj@FreeBSD.org> |
Fix a harmless LOR in dtrace_load().
MFC after: 1 week
|
| #
0ed76ec8
|
| 24-Nov-2016 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r308870 through r309105.
|
| #
cdaa8777
|
| 23-Nov-2016 |
George V. Neville-Neil <gnn@FreeBSD.org> |
Add tunable to disable destructive dtrace
Submitted by: Joerg Pernfuss <code.jpe@gmail.com> Reviewed by: rstone, markj MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D8624
|
| #
fdce57a0
|
| 14-May-2016 |
John Baldwin <jhb@FreeBSD.org> |
Add an EARLY_AP_STARTUP option to start APs earlier during boot.
Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI
Add an EARLY_AP_STARTUP option to start APs earlier during boot.
Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI_SUB_SMP at which point they are released to run kernel threads. SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter the scheduler and start running threads until fairly late in the boot.
This change moves SI_SUB_SMP up to just before software interrupt threads are created allowing the APs to start executing kernel threads much sooner (before any devices are probed). This allows several initialization routines that need to perform initialization on all CPUs to now perform that initialization in one step rather than having to defer the AP initialization to a second SYSINIT run at SI_SUB_SMP. It also permits all CPUs to be available for handling interrupts before any devices are probed.
This last feature fixes a problem on with interrupt vector exhaustion. Specifically, in the old model all device interrupts were routed onto the boot CPU during boot. Later after the APs were released at SI_SUB_SMP, interrupts were redistributed across all CPUs.
However, several drivers for multiqueue hardware allocate N interrupts per CPU in the system. In a system with many CPUs, just a few drivers doing this could exhaust the available pool of interrupt vectors on the boot CPU as each driver was allocating N * mp_ncpu vectors on the boot CPU. Now, drivers will allocate interrupts on their desired CPUs during boot meaning that only N interrupts are allocated from the boot CPU instead of N * mp_ncpu.
Some other bits of code can also be simplified as smp_started is now true much earlier and will now always be true for these bits of code. This removes the need to treat the single-CPU boot environment as a special case.
As a transition aid, the new behavior is available under a new kernel option (EARLY_AP_STARTUP). This will allow the option to be turned off if need be during initial testing. I plan to enable this on x86 by default in a followup commit in the next few days and to have all platforms moved over before 11.0. Once the transition is complete, the option will be removed along with the !EARLY_AP_STARTUP code.
These changes have only been tested on x86. Other platform maintainers are encouraged to port their architectures over as well. The main things to check for are any uses of smp_started in MD code that can be simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in the EARLY_AP_STARTUP case (e.g. the interrupt shuffling).
PR: kern/199321 Reviewed by: markj, gnn, kib Sponsored by: Netflix
show more ...
|
| #
98e0ffae
|
| 27-May-2015 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge sync of head
|
| #
9f3d45b6
|
| 08-Feb-2015 |
Baptiste Daroussin <bapt@FreeBSD.org> |
Merge from HEAD
|
| #
a403ab7f
|
| 04-Feb-2015 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r278110 through r278223.
|
| #
eadcd0fa
|
| 03-Feb-2015 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
MFV r266993:
4469 DTrace helper tracing should be dynamic
Reference: https://illumos.org/issues/4469
Obtained from: Illumos Phabric: D1551 Reviewed by: markj MFC after: 2 weeks
|
| #
246e7a2b
|
| 02-Sep-2014 |
Neel Natu <neel@FreeBSD.org> |
IFC @r269962
Submitted by: Anish Gupta (akgupt3@gmail.com)
|
| #
ee7b0571
|
| 19-Aug-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge head from 7/28
|
| #
1b833d53
|
| 13-Aug-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Sync to HEAD@r269943.
|
| #
a99098e2
|
| 25-Jun-2014 |
Davide Italiano <davide@FreeBSD.org> |
Continue the crusade towards a dev_clone()-free kernel, removing its usage from dtrace. The dtrace code already uses cdevpriv(9) since FreeBSD 8, so this change should be quite harmless.
Reviewed by
Continue the crusade towards a dev_clone()-free kernel, removing its usage from dtrace. The dtrace code already uses cdevpriv(9) since FreeBSD 8, so this change should be quite harmless.
Reviewed by: markj Approved by: markj MFC after: never
show more ...
|
| #
6cec9cad
|
| 03-Jun-2014 |
Peter Grehan <grehan@FreeBSD.org> |
MFC @ r266724
An SVM update will follow this.
|
| #
3b8f0845
|
| 28-Apr-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge head
|
| #
84e51a1b
|
| 23-Apr-2014 |
Alan Somers <asomers@FreeBSD.org> |
IFC @264767
|
| #
5748b897
|
| 19-Feb-2014 |
Martin Matuska <mm@FreeBSD.org> |
Merge head up to r262222 (last merge was incomplete).
|
| #
485ac45a
|
| 04-Feb-2014 |
Peter Grehan <grehan@FreeBSD.org> |
MFC @ r259205 in preparation for some SVM updates. (for real this time)
|
| #
e01ff621
|
| 09-Jan-2014 |
Glen Barber <gjb@FreeBSD.org> |
MFH: tracking commit (head@r260486)
Sponsored by: The FreeBSD Foundation
|