NAS-139725 / 25.10.2 / Add protections against partially-written truenas-grub.cfg (by anodos325) (#18179)
This commit ensures that we are always atomically replacing the truenas
grub configuration.
Original PR: https://github.com/truenas/middleware/pull/18173
---------
Co-authored-by: Andrew Walker <andrew.walker at truenas.com>
[LV] Don't scalarize loads that need predication in legacy CM.
The legacy cost model tries to scalarize loads that are used as
pointers. Skip if the load would need predicating when scalarized,
because that would incur very high costs, see useEmulatedMaskMemRefHack.
Fixes https://github.com/llvm/llvm-project/issues/180780.
[DominanceFrontier] Support post-dominators on graphs with single root (#179336)
I plan to use that to optimize mask creation in VPlan predicator by
`or`ing edge masks from the post-dominance frontier instead of all
predecessors in a subsequent patch. Note that it would require to use
the same unmodified post-dom tree for *all* the basic blocks in a VPlan
that is already limited to a particular loopnest so the algorithmic
complexity concerns behind the "deprecation" notice in the beggining of
`DominanceFrontier.h` (and also discussion in the
https://discourse.llvm.org/t/dominance-frontiers/21755 thread) don't
apply for my use case (at least to the best of my understanding).
The change here is to properly use graph-traits for children traversal
plus inline `ForwardDominanceFrontierBase` into `DominanceFrontierBase` now
that it's used for post-dom-frontier.
Since the only planned use-case is in the vectorizer, I'm adding a
VPlan-base unittest along with this change.
[2 lines not shown]
NAS-139743 / 26.0.0-BETA.1 / Fix typo in truenas-grub (#18186)
This commit fixes a typo in keyword arguments in truenas-grub.py. During
refactoring of in-progress code, a keyword argument had its name changed
unexpectedly resulting in mismatch between call-site and function
signature.
hwpstate_amd(4): Rename '*set_autonomous_hwp*()' => 'enable_cppc*()'
This is to better reflect that we are really enabling CPPC in these
functions and because we are likely to stop activating CPPC autonomous
mode by default in the near future.
No functional change (intended).
Sponsored by: The FreeBSD Foundation
hwpstate_amd(4): Style: Align 'machdep.hwpstate_amd_cppc_enable'
Align it like the rest.
No functional change (intended).
Sponsored by: The FreeBSD Foundation
hwpstate_amd(4): Rename PSTATE_CPPC internal flag
While here, also rename check_cppc_enabled() => check_cppc_in_use().
No functional change (intended).
Sponsored by: The FreeBSD Foundation
hwpstate_amd(4): 'epp' sysctl leaf to operate on real EPP hardware values
We were using percents, for compatibility with hwpstate_intel(4), but
this looses granularity that might be important in some scenarios or
with specific CPU models.
For consistency, hwpstate_intel(4) should be changed accordingly, at the
expense of breaking compatibility.
For release notes: Introduction of hwpstate_amd(4) deserves a release
note, even if the original commit was not tagged. Functionality
introduced by recent commits tagged with "Relnotes" should be mentioned
along that one.
PR: 292615
Reviewed by: aokblast
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55009
hwpstate_amd(4): Add knobs to get/set all fields of CPPC_REQUEST
This will allow experimentations and finer-grained tuning to the full
extent allowed by the hardware, which is especially important given that
the spec leaves to hardware implementors an important leeway in
interpreting CPPC's numeric parameters, causing the same settings to
have different effects on different CPU models.
PR: 292615
Reviewed by: aokblast (older version)
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55010
hwpstate_amd(4): Sane defaults for min/max perf on insane capabilities
If the CPPC_CAPABILITY_1 register stays at its reset value (0) even
after enabling CPPC, as observed in the field (see the referenced PR
below), use sane min/max performance limits as hinted by the ACPI spec,
i.e., all 0s for the minimum value and all 1s for the maximum one.
While here, let's cope upfront with some more insane situations, where
the minimum value would be greater than the maximum one, but also if
they would be equal which does not seem to make sense at all in the CPPC
frame (and, anyway, in this case, the actual minimum and maximum values
we program should have no effect at all). That last case actually also
covers the one exposed in the previous paragraph.
PR: 292615
Reviewed by: aokblast
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55007
hwpstate_amd(4): Factor out setting the CPPC_REQUEST register
In preparation for creating other knobs to tweak values in this register
beyond just the EPP (Efficiency/Performance Preference).
While here, add a herald comment before the softc structure indicating
how we achieve atomicity when modifying the softc.
Reviewed by: aokblast
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55008
hwpstate_amd(4): attach(): More diagnostic on CPPC enable
When the 'debug.hwpstate_verbose' tunable/sysctl knob is set, dump the
initial content of the CPPC_CAPABILITY_1 and CPPC_REQUEST registers.
If, after enabling CPPC, reading/writing some MSR fails during the attach
sequence, print a diagnostic. However, once CPPC is enabled, we cannot
go back (disabling it is impossible), so we'll attach even if fiddling
with other MSRs failed.
While here, move diagnostic printing on attach out of the callback that
is executed on (potentially) another CPU and with interrupts disabled,
putting it into the attach routine itself.
While here, fix format for printing the CPU ID.
PR: 292615
Reviewed by: aokblast (older version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55006
hwpstate_amd(4): Register dump: Fine-grained error reporting
If some of the registers cannot be read, report that but continue trying
reading the others. This also has the side benefit of simplifying code.
While here, use sbuf_new_for_sysctl(), and rename 'res' and 'ret', which
are to contain error values, to 'error'.
While here, remove the test on getting the per-cpu structure, as if it
is not present we would have already crashed on device attach.
While here, fix format for printing the CPU ID.
PR: 292615
Reviewed by: aokblast (older version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55005
[LLDB]Move clean up to dtor (#181010)
I attempted to cleanup the raw ptr in pr/180996. But the cleanup should
have been done in the dtor, not `StopPrivateStateThread` so moving it
there.
[AMDGPU][ISel] `setcc` peephole for comparisons with upper 32 bits of a 64-bit register pair (#177662)
This optimisation is motivated by [this minimal
example](https://godbolt.org/z/9o83GvGsM).
Particularly, if `mask` is a 64-bit integer, a select
```cpp
auto out = ((mask >> 32) != 0) ? a : b;
```
converts the null-check on the higher 32-bits of `mask` into a
`v_cmp_lt_u64` with the integer `1 << 32` stored in a pair of VGPRs
(effectively wasting two VGPRs).
More generally, if a 64-bit integer (whose lower 32 bits are known to be
irrelevant) is compared with a 64-bit constant, two VGPRs are wasted to
construct this constant.
This patch modifies ISel to take advantage of how 64-bit values are
stored in pairs of VGPRs (or SGPRs), and truncates the 64-bit constant
[3 lines not shown]
NAS-139600 / 26.0.0-BETA.1 / Update text to replace 'ixsystems' and 'iX' with 'TrueNAS (#18184)
Update customer facing text to replace 'ixsystems' and 'iX' with
'TrueNAS'.
The license nag messages were also cleaned and tightened.
Expand use of atomic_write() helper
This commit expands use of atomic_write() to places where there
is risk that a partial file write can impact stability or
predictable server behavior.
