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]
[lldb][RISCV] Fix x8 register aliasing for gdb-remote targets (#209070)
GDB remote target descriptions can expose the RISC-V `x8` register as
`fp`. LLDB previously used `fp` as the primary name and `s0` as the
alternate name, leaving no register name for `x8`.
This commit changes `s0` as the primary name, `x8` as the alternate
name, and mark the register as the generic frame pointer. Allowing `fp`,
`s0`, and `x8` to resolve to the same register.
Fixes #127900
[clang-tidy][docs] Remove obsolete doc8 instructions. NFC. (#210576)
Remove the doc8 setup and invocation instructions from the contributing
guide as clang-tidy documentation transitions to Markdown.
Part of https://github.com/llvm/llvm-project/issues/201242
[GlobalISel] Add `isKnownNeverZero` to `GISelValueTracking` (#198438)
## Summary of changes
* This patch adds `GISelValueTracking::isKnownNeverZero`, modeled after
the SelectionDAG query, and uses it in the GlobalISel count-zero
combiner.
* The root combines enabled by this patch are:
* `G_CTLZ x -> G_CTLZ_ZERO_POISON x`
* `G_CTTZ x -> G_CTTZ_ZERO_POISON x`
* The combine only fires when the source is known nonzero and the
zero-poison opcode is legal, or when the combiner is running before
legalization.
* For the initial proof set, this patch handles `G_OR`, `G_SELECT`, and
`G_SHL`. These are not new root combines; they are source-expression
cases used by `isKnownNeverZero` to prove that the input to `G_CTLZ` /
`G_CTTZ` is nonzero. Other structural cases can be added in follow-up
patches. For other opcodes, the query falls back to existing KnownBits
[21 lines not shown]
Don't use SCSI_DATA_IN for patrol read commands that don't have a data
buffer. Noticed while looking into crashes reported by job@ but doesn't
fix anything.
ok dlg@
[CycleInfo] Identify cycles with a single-pass DFS algorithm (#210491)
Replace the Havlak-Tarjan construction in GenericCycleInfoCompute, a DFS
followed by a reverse-preorder scan, with the single-pass algorithm of
Wei, Mao, Zou and Chen, "A New Algorithm for Identifying Loops in
Decompilation" (SAS 2007). One depth-first traversal tags every block
with its innermost loop header on the fly; tagLoopHeader weaves the
per-block header chains, replacing UNION-FIND.
The flat forest is reconstructed from the tags, dropping the temporary
cycle objects and the per-block worklist passes. An edge re-entering an
already-closed cycle records non-header entries, so entries need no
predecessor scan.
The cycle sets, headers, reducibility and nesting are identical for the
given DFS order, cross-checked against the old construction on random
reducible and irreducible CFGs. Two implementation-defined orders change
(with minor test churn): sibling cycles are laid out in decreasing
header preorder, and non-header entries in block preorder.
[6 lines not shown]
Revert "[flang][OpenMP] Fix new metadirective-loop-nest.f90 test expectation with collapse changes in #208528" (#210860)
Reverts llvm/llvm-project#210753
Revert with #208528 pending llvm-test-suite fix.
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)
[Clang][AIX] Switch -mloadtime-comment-vars name matching to mangled IR names
Replace source-qualified name matching in matchesLoadTimeCommentVarName with
mangled IR symbol name matching via getMangledName(GlobalDecl(VD)).
[ProfileData] Refactor SampleProfileNameTable into a polymorphic class hierarchy (NFC) (#210252)
This patch refactors SampleProfileNameTable into an abstract base
class with concrete derived classes like LazySampleProfileNameTable
and EagerSampleProfileNameTable.
The motivation is twofold:
- I want each derived class to focus on one data representation
instead of using complex if-then-else. Plus, I'm planning to
introduce one more data representation [1].
- I want each class to be populated and ready for use as soon as it is
constructed. That is, there is no intermediate state like
"constructed but waiting to be populated".
Now, you might notice that the iterator uses virtual operator[]. I
would argue that this is acceptable. We have three places where we
iterate over the entire range of the name table entries. Two of
[8 lines not shown]
