sched_4bsd: Allocate runqueues only for present CPUs
4BSD has been allocating an array of MAXCPU runqueues, runq_pcpu[],
instead of one runqueue per actually present CPU. On amd64, MAXCPU is
1024 and 'struct runq' is 4128 bytes, causing runq_pcpu[] to take more
than 4 MiB of memory. On the vast majority of current systems, which
have at most 32 cores with SMT, this is a waste of memory.
Besides providing per-CPU runqueues, runq_pcpu[] has also been used to
determine the CPU ID of a given thread's associated runqueue through
pointer arithmetic.
Since per-CPU structures are only allocated for present CPUs, in order
to save space, move the runqueues to per-CPU fields and, for each thread
('struct ts_sched'), replace its runqueue pointer by the CPU ID of the
runqueue it is in (new 'ts_rqcpu' field). Set the thread's CPU ID to
the special NOCPU value when it is running on the global runqueue.
Drop the SKE_RUNQ_PCPU() macro as it is now simply equivalent to
[11 lines not shown]
sched_4bsd: Rename the global runqueue
In an upcoming change whose purpose is to stop having 4BSD always
allocate MAXCPU runqueues, wasting space on most machines, 'struct
td_sched' will store the CPU ID to which a thread is bound/pinned
instead of a pointer to the corresponding runqueue. As a consequence,
existing functions manipulating a thread's runqueue will need to point
to the inferred runqueue through a local variable. The name 'runq' is
the ideal one for these local variables, but before this change it
designated the global runqueue, also causing unnecessary ambiguity.
Thus, rename the global runqueue to the more explicit 'runq_global'.
Arguably, this should have been performed as part of commit e17c57b14ba9
("- Implement cpu pinning and binding. (...)").
No functional change (intended).
[olce: Massaged the commit message. Tested with source builds.]
[5 lines not shown]
sched_4bsd: Remove obsolete SMP scaling for ticks per priority level
The INVERSE_ESTCPU_WEIGHT scaling had been introduced by commit
b698380f33ef ("Quick fix for scaling of statclock ticks in the SMP
case. ...") to leave more discrimination room for multiple CPUs possibly
adding their ticks to the same 'struct ksegrp' (but also slightly
changing how CPU hogs are penalized).
Then, commit 8460a577a4b4 ("Make KSE a kernel option, ...") introduced
the current thread-based code, where tick accounting is only done on the
current thread, which renders this trick obsolete on !KSE.
Finally, when KSE was removed, the trick became generally obsolete.
The trick is actually even harmful because it changes the intended
behavior of priorizing more the CPUs that use the less ticks (and so,
impairs boosting "interactive" processes).
Remove it now. Clamping of 'ts_estcpu' and its relation to the
[6 lines not shown]
sched_4bsd: Fix conflating priority of differently-niced CPU-bound threads
We introduced (PRI_MAX_TIMESHARE - PRI_MIN_TIMESHARE) as part of
ESTCPULIM() in commit eebc148f25c3 ("sched_4bsd: ESTCPULIM(): Allow any
value in the timeshare range") in order to use more than a fixed number
(40) of all the available priority levels in the timeshare range (136
before the 256-queue runqueue work, 224 now) to take into account the
number of ticks a thread has run ('ts_estcpu').
In the computation of a new thread's priority (resetpriority()), in
addition to the "ticks running" contribution, the final priority also
includes a "nice" value contribution. The final value is clamped into
the [PRI_MIN_TIMESHARE; PRI_MAX_TRIMESHARE] range.
Problem is that the new "ticks running" contribution now can lead to
a computed priority value that exceeds PRI_MAX_TRIMESHARE, and is thus
finally clamped to PRI_MAX_TIMESHARE, which becomes an alias for all
out-of-bound values. In particular, this can conflate CPU-hungry
threads. With at least two of them competing on the same CPU, with an
[20 lines not shown]
nfsd: Optionally enable use of M_EXTPG mbufs for read replies
A test site determined that, for a Mellanox NIC which can handle
M_EXTPG mbufs, an improvement of 5-15% for read rate could be
achieved if the read reply was in M_EXTPG mbufs.
A patch that tried to determine if the outbound NIC supported
M_EXTPG mbufs (IFCAP_MEXTPG) did not pass review.
However, it does appear that this can be useful for NFS-over-RDMA.
(Which just happen to use NICs that do support M_EXTPG mbufs.)
As such, this patch enables them is xp_extpg is set to true,
which is never for now, but might be set true for RDMA or
when vfs.nfsd.enable_mextpg is set non-zero. (It is 0 by
default, so this is never enabled by default at this time.)
(cherry picked from commit d516e52373e1768ea84bf1ca220671a44f413abe)
firewire: replace magic numbers with named constants
No functional change.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D58311
firewire: force root change when root node is not cycle master capable
When a FireWire bus resets, all devices negotiate who is the new boss.
when we detect the root node can't be cycle master,
we send a PHY config packet that forces a reelection.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D58309
firewire: drain pending xfers after callout stop in detach
Removes a TODO that predates the existing drain call.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D58308
firewire: add warn-only CRC validation for CSR ROM directories
Implemented crom_crc_valid() helper to validate IEEE 1394 config ROM CRC-16
checksums.
Skipped root header CRC validation since csrhdr.crc_len cover the entire
ROM body which is not fully read at header parse time. Per-directory
CRC checks below catch corruption where it needed.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D58307
net80211: update drivers to allocate sequence numbers in the raw path
A bunch of drivers weren't properly converted. I mistakenly
put a call to ieee80211_output_seqno_assign() wherever the
crypto header was added, which isn't exactly correct.
There are plenty of drivers which don't share enough of their
raw and normal transmit path code for that to hold true.
So after some manual review, it looks like I've captured the
places (outside of iwn(4) which I committed earlier) where
I missed ieee80211_output_seqno_assign() calls.
* For bwi(4) and bwn(4) I refactored it out into a place that is
common enough and happens in the same lock hold window,
so it's serialised.
* For the rest, it's just plain missing from the raw path.
Locally tested:
[6 lines not shown]
aq(4): Document the Atlantic 2 (AQC113/114/115/116) devices
List every AQC part aq_vendor_info_array[] probes, each with the
maximum speed aq_hw_capabilities() grants it.
Only the Atlantic 2 parts link at 10 Megabit. The AQC100 and AQC100S
are the only SFP+ controllers; the rest are twisted pair.
Reviewed by: adrian, ziaee
Signed-off-by: Nick Price <nick at spun.io>
Differential Revision: https://reviews.freebsd.org/D58144
vidcontrol: Disallow -i mode with vt(4)vt(4) does not (currently) support changing the video mode. Report that
-i mode is not supported rather than printing an empty list.
PR: 207411
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D58163
lookup: do not return vp_crossmp as dvp for mount over the reg file
Return the covered vnode instead.
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D58191
sh.1: Document which features are non-POSIX
Point out which features are non-POSIX and thus can not be
safely assumed to be portable and exist in other implementations.
Relnotes: YES!
Reviewed by: ziaee, jilles
Differential Revision: https://reviews.freebsd.org/D55333
amd64: FRED support
FRED support as defined starting from the SDM rev. 90, requires a new
'events' entry point to receive user and kernel mode exceptions and
interrupts notifications from the hardware. A minimal asm trampoline is
enough, rest can be implemented in C due to the clean FRED organization
of the event reporting.
The syscall entry is handled by a microptimized assembly path, directly
calling into the amd64_syscall() handler, instead of the generic events
entry point.
Tested by: emaste
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D55829
x86 xen: provide the prototype for xen_arch_intr_handle_upcall() in x86/apicvar.h
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D56005
if_geneve: Fix mbuf leak on ip_ecn_egress
Free mbuf and increase IFCOUNTER_IERRORS if ip_ecn_egress() under
geneve_input_inherit() decides to drop the packet.
Reported by: Chris Jarrett-Davies of the OpenAI Codex Security Team
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D58361
linuxkpi: Add pm_runtime_resume_and_get
pm_runtime_resume_and_get is used by new versions of amdgpu, and began
use between Linux kernel version 6.12, and 6.14.
Reviewed by: dumbbell
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57463
(cherry picked from commit 7e1245aafeece1a56af292c2652c6b835ccb6f10)
vtfontcvt: Avoid dead store in add_char
The fallback glyph is stored at index 0, and does not need to be
inserted into a mapping.
Previously there was a dead store of add_glyph's return value for the
fallback case, which upset Clang's static analyzer. Now, cast the
return value to (void) to make it clear this is intentional.
Also change add_glyph's fallback parameter to a c99 bool to make its use
more clear.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57174
