linuxkpi: Add tag support to radix tree
The tag is used to perform lookup in a different way.
New functions were introduced:
* to set, check and clear a tag
* to walk through a radix tree based on a given tag
Furthermore, the `radix_tree_delete()` function was modified to clear
tags on deletion.
The amdgpu DRM driver started to use this in Linux 6.10.
While here, the `radix_tree_gang_lookup()` function was added because it
is very close to `radix_tree_gang_lookup_tag()`, but it is not used by
the DRM drivers as of this commit.
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54503
(converters/orcus) +USE_CXX_FEATURES = c++20, implying for gcc12
NetBSD/amd64 9.x fails with following line, later releases are OK.
In file included from /usr/include/g++/memory:80:0,
from ../../include/orcus/stream.hpp:13,
from stream.cpp:8:
/usr/include/g++/bits/unique_ptr.h: In instantiation of 'typename std::_MakeUniq<_Tp>::__single_object std::make_unique(_Args&& ...) [with _Tp = orcus::file_content::impl; _Args = {std::basic_string_view<char16_t, std::char_traits<char16_t> >&}; typename std::_MakeUniq<_Tp>::__single_object = std::unique_ptr<orcus::file_content::impl>]':
stream.cpp:191:44: required from here
/usr/include/g++/bits/unique_ptr.h:821:30: error: no matching function for call to 'orcus::file_content::impl::impl(std::basic_string_view<char16_t>&)'
{ return unique_ptr<_Tp>(new _Tp(std::forward<_Args>(__args)...)); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
interfaces: multi-dhcp6c support and custom PD association #7647
This splits off rtsold and dhcp6c into separate processes
which frees us from the restrictions of faked iterative IDs
for PD associations. For NA we simply default to 0 now.
I'm not entirely sure why we settled for a single deamon of
dhcp6c back in the day, but there are certianly downsides to
it and I don't see something that wasn't fixed in the meantime
that makes this not work.
[Github] Make libcxx-check-generated-files.yml not run in forks
This is best practice according to
https://llvm.org/docs/CIBestPractices.html. Found this when looking at
PRs on forks and saw one running for libc++.
vtnet: remove M_HASHTYPE when there is only one pair of rx/tx queue
Summary:
Doing so will let the upper layer know how to deal with software hash,
with benefits like inp_flowid can be set and m_pkthdr.flowid can be set
in output path.
Reviewed by: tuexen
Differential Revision: https://reviews.freebsd.org/D54929
In uvm_pdaemon.c 1.121, 1.122, and 1.123, two things happened:
1. The shortage target inside uvmpd_scan() / uvmpd_scan_inactive() which
used to be computed using the realtime uvmexp.free value, was replaced with a
(historic prediction) using the pre-existing pagedaemon "shortage" variable.
This means the scanner will continue work even if the system recovers
memory asyncronously and has resolved the scarcity which caused the pagedaemon
to be summoned. That's a bad idea. The code should revert to observing
realtime system conditions. We don't have a diff for that yet, but the
other concern is immediate:
2. The pre-existing calculation of the "shortage" variable was changed
significally, without verifying correct behaviour.
size += shortage;
...
shortage -= bufbackoff(&constraint, size * 2);
since bufbackoff() returns how much it did, and generally succeeds at
satisfying the full request size * 2, that is effectively "shortage =
-shortage". The scan function changes still expect a positive target
[5 lines not shown]
[mlir] Add [may]updateStartingPosition to VectorTransferOpInterface
This commit adds methods to VectorTransferOpInterface that allow
transfer operations to be queried for whether their base memref (or
tensor) and permutation map can be updated in some particular way and
then for performing this update. This is part of a series of changes
designed to make passes like fold-memref-alias-ops more generic,
allowing downstream operations, like IREE's transfer_gather, to
participate in them without needing to duplicate patterns.
[mlir][MemRef] Make fold-memref-alias-ops use memref interfaces
This replaces the large switch-cases and operation-specific patterns
in FoldMemRefAliashops with patterns that use the new
IndexedAccessOpInterface and IndexedMemCopyOpInterface, which will
allow us to remove the memref transforms' dependency on the NVGPU
dialect.
This does also resolve some bugs and potential unsoundnesses:
1. We will no longer fold in expand_shape into vector.load or
vector.transfer_read in cases where that would alter the strides
between dimensions in multi-dimensional loads. For example, if we have
a `vector.load %e[%i, %j, %k] : memref<8x8x9xf32>, vector<2x3xf32>`
where %e is
`expand_shape %m [[0], [1], [2. 3]] : memref<8x8x3x3xf32> to 8x8x9xf32,
we will no longer fold in that shape, since that would change which
value would be read (the previous patterns tried to account for this
but failed).
2. Subviews that have non-unit strides in positions that aren't being
[15 lines not shown]
[mlir] Implement indexed access op interfaces for memref, vector, gpu, nvgpu
This commit implements the IndexedAccessOpInterface and
IndexedMemCopyInterface for all operations in the memref and vector
dialects that it would appear to apply to. It follows the code in
FoldMemRefAliasOps and ExtractAddressComputations to define the
interface implementations. This commit also adds the interface to the
GPU subgroup MMA load and store operations and to any NVGPU operations
currently being handled by the in-memref transformations (there may be
more suitable operations in the NVGPU dialect, but I haven't gone
looking systematically)
This code will be tested by a later commit that updates
fold-memref-alias-ops.
Assisted-by: Claude Code, Cursor (interface boilerplate, sketching out
implementations)
[mlir][memref] Define interfaces for ops that access memrefs at an index (#177013)
This commit defines interfaces for operations that perform certain kinds
of indexed access on a memref. These interfaces are defined so that
passes like fold-memref-alias-ops and the memref flattener can be made
generic over operations that, informally, have the forms `op ... %m[%i0,
%i1, ...] ...` (an IndexedAccessOpInterface) or the form `op %src[%s0,
%s1, ...], %dst[%d0, %d1, ...] size ...` (an IndexedMemCopyOpInterface).
These interfaces have been designed such that all the passes under
MemRef/Transforms that currently have a big switch-case on memref.load,
vector.load, nvgpu.ldmatrix, etc. can be migrated to use them.
(This'll also let us get rid of the awkward fact that we have memref
transforms depending on the GPU and NVGPU dialects)
While the interface doesn't currently contemplate changing element types
(enabling, for example, writing a bf16 => u16 update to be done in
place), future extensions to allow such transformations could be worth
[7 lines not shown]
interfaces: generalise the dhcp6c_script using the new IFNAME variable #7647
Now that the new dhcp6c code is in 26.1 we can start using it.
The file was conceptually created inline via d36f0f4f62557 and before was
a single command line script... so add appropriate copyrights from that
time onward.
Many thanks to Martin for pinoeering this back in the day!
capsicum-test: Move out of contrib
Google developed the Capsicum unit test suite[1] as part of the
Capsicum-Linux[2] project, based on unit tests that existed in FreeBSD
and unit tests developed as part of the initial Capsicum-Linux port.
Capsicum-Linux was archived as of October 31, 2022 and is no longer
being maintained. FreeBSD is currently the only consumer of and
contributor to the test suite. Move the src into tests/sys/capsicum to
simplify ongoing maintenance.
The makefiles were deleted as we (continue to) use the existing bespoke
FreeBSD Makefile, and CONTRIBUTING.md was removed as the Google CLA is
no longer applicable.
[1] https://github.com/google/capsicum-test
[2] https://github.com/google/capsicum-linux
Reviewed by: asomers, oshogbo
[2 lines not shown]
The pagedaemon inspects the top-most sleeping pmemrange allocation for
for size and constraint, and passes this information to the inactive
scanner. The idea is that an extremely high-size and
strict-constraint allocation that fails repeatedly would percolate to
the top of the list. To ensure the scanner can inspect this
allocation's constraint via the pointer, it gets locked. Then we
release tons of memory from the buffer cache, and run the scanner to
recover free memory. At the same time, other running operations free
and allocate memory and wakeup all the sleeping pmemrange allocations,
but no, not this one, because it is locked so that the pointer won't
become invalid. When the scan is done, we may once again have meager
memory resources because all the good stuff was allocated by
asyncronous allocators, potentially creating substantial fragmentation
not compatible with the constraint. Now, the sleeping request gets
unlocked and woken to re-check it's requirements and guess what, the
constraint fails it goes back to sleep, and we need to go around
again... In practice this is a hard uvm deadlock.
Instead, copy the constraint from the request, do not lock the
allocation request and ignore the pointer.
[4 lines not shown]
[clang-tidy] Add llvm-type-switch-case-types check (#177892)
Adds a new check for `llvm::TypeSwitch`:
* `.Case<T>([](T *X) { ... })` --> `.Case([](T *X) { ... } )`
* `.Case<T>([](auto X) { ... })` --> warning only
I ran this on mlir to make sure the warning make sense and that all
fixits compile:
https://gist.github.com/kuhar/a2276a2364325521ea6f39d2098497b9.
Assisted-by: claude
