History log of /src/sys/cddl/dev/dtrace/dtrace_load.c (Results 1 – 25 of 150)
Revision Date Author Comments
# 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


123456