| /linux/Documentation/ |
| A D | atomic_bitops.txt | 5 While our bitmap_{}() functions are non-atomic, we have a number of operations
12 The single bit operations are:
18 RMW atomic operations without return value:
23 RMW atomic operations with return value:
33 All RMW atomic operations have a '__' prefixed variant which is non-atomic.
47 The test_and_{}_bit() operations return the original value of the bit.
55 - non-RMW operations are unordered;
57 - RMW operations that have no return value are unordered;
59 - RMW operations that have a return value are fully ordered.
61 - RMW operations that are conditional are fully ordered.
[all …]
|
| A D | atomic_t.txt | 5 RMW operations between CPUs (atomic operations on MMIO are not supported and
20 RMW atomic operations:
138 - plain operations without return value: atomic_{}()
146 - operations which return the original value: atomic_fetch_{}()
148 - swap operations: xchg(), cmpxchg() and try_cmpxchg()
155 All these operations are SMP atomic; that is, the operations (for a single
165 - non-RMW operations are unordered;
167 - RMW operations that have no return value are unordered;
169 - RMW operations that have a return value are fully ordered;
171 - RMW operations that are conditional are unordered on FAILURE,
[all …]
|
| /linux/tools/memory-model/Documentation/ |
| A D | ordering.txt | 2 operations provided by the Linux-kernel memory model (LKMM).
9 operations in decreasing order of strength:
13 subsequent operations.
83 operations include value-returning RMW atomic operations (that is, those
247 a. Release operations.
249 b. Acquire operations.
292 There is a wide variety of release operations:
443 a. Unordered marked operations.
457 These operations come in three categories:
465 operations, unless these operations are to the same variable.
[all …]
|
| /linux/Documentation/virt/ |
| A D | paravirt_ops.rst | 11 hypervisors. It allows each hypervisor to override critical operations and
15 pv_ops provides a set of function pointers which represent operations
18 time by enabling binary patching of the low-level critical operations
21 pv_ops operations are classified into three categories:
24 These operations correspond to high-level functionality where it is
28 Usually these operations correspond to low-level critical instructions. They
|
| /linux/Documentation/arch/arm/ |
| A D | firmware.rst | 2 Interface for registering and calling firmware-specific operations for ARM
10 operations and call them when needed.
12 Firmware operations can be specified by filling in a struct firmware_ops
21 There is a default, empty set of operations provided, so there is no need to
22 set anything if platform does not require firmware operations.
33 Example of registering firmware operations::
52 /* other operations not available on platformX */
|
| /linux/Documentation/core-api/ |
| A D | this_cpu_ops.rst | 2 this_cpu operations
8 this_cpu operations are a way of optimizing access to per cpu
14 this_cpu operations add a per cpu variable offset to the processor
24 Read-modify-write operations are of particular interest. Frequently
39 (remote write operations) of local RMW operations via this_cpu_*.
42 operations.
45 are defined. These operations can be used without worrying about
64 Inner working of this_cpu operations
127 Special operations
166 cpu variable. Most this_cpu operations take a cpu variable.
[all …]
|
| A D | local_ops.rst | 11 This document explains the purpose of the local atomic operations, how
18 Note that ``local_t`` based operations are not recommended for general
19 kernel use. Please use the ``this_cpu`` operations instead unless there is
21 replaced by ``this_cpu`` operations. ``this_cpu`` operations combine the
26 Purpose of local atomic operations
29 Local atomic operations are meant to provide fast and highly reentrant per CPU
30 counters. They minimize the performance cost of standard atomic operations by
39 Local atomic operations only guarantee variable modification atomicity wrt the
50 It can be done by slightly modifying the standard atomic operations: only
63 Rules to follow when using local atomic operations
[all …]
|
| /linux/Documentation/bpf/standardization/ |
| A D | instruction-set.rst | 424 Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31)
425 for 32-bit operations.
591 MEM 3 regular load and store operations `Regular load and store operations`_
592 MEMSX 4 sign-extension load operations `Sign-extension load operations`_
593 ATOMIC 6 atomic operations `Atomic operations`_
615 Regular load and store operations
636 Sign-extension load operations
649 Atomic operations
652 Atomic operations are operations that operate on memory and can not be
656 All atomic operations supported by BPF are encoded as store operations
[all …]
|
| /linux/Documentation/gpu/ |
| A D | drm-vm-bind-async.rst | 16 an IOCTL. The operations include mapping and unmapping system- or
57 operation. VM_BIND operations that use the same bind context can be
94 Since asynchronous VM_BIND operations may use dma-fences embedded in
109 operations for long-running workloads will not allow for pipelining
121 deeply pipelined behind other VM_BIND operations and workloads
126 created. For each context, VM_BIND operations will be guaranteed to
138 the kernel mode driver to inject other operations into the bind /
144 There is no difference in the operations supported or in
163 Unbind operations are guaranteed not to return any errors due to
174 zero, one or many such operations. A zero number means only the
[all …]
|
| /linux/Documentation/admin-guide/device-mapper/ |
| A D | delay.rst | 15 3: apply offset and delay to read, write and flush operations on device
18 to write and flush operations on optionally different write_device with
35 # Create mapped device named "delayed" delaying read, write and flush operations for 500ms.
42 # Create mapped device delaying write and flush operations for 400ms and
|
| /linux/Documentation/crypto/ |
| A D | async-tx-api.rst | 15 3.2 Supported operations
36 the API will fit the chain of operations to the available offload
54 operations to be submitted, like xor->copy->xor in the raid5 case. The
71 3.2 Supported operations
97 operations complete. When an application needs to submit a chain of
113 async_<operation> call. Offload engine drivers batch operations to
116 automatically issues pending operations. An application can force this
129 chains and issuing pending operations.
143 2. Completion callback routines cannot submit new operations. This
207 handle submission of dependent operations
[all …]
|
| /linux/Documentation/mm/damon/ |
| A D | design.rst | 33 operations set layer, and
61 operations set. If there is no available operations set for a given purpose, a
334 Supported by ``vaddr`` and ``fvaddr`` operations set.
336 Supported by ``vaddr`` and ``fvaddr`` operations set.
340 Supported by ``vaddr`` and ``fvaddr`` operations set.
342 Supported by ``vaddr`` and ``fvaddr`` operations set.
344 Supported by ``paddr`` operations set.
346 Supported by ``paddr`` operations set.
348 Supported by ``paddr`` operations set.
350 Supported by ``paddr`` operations set.
[all …]
|
| /linux/Documentation/filesystems/iomap/ |
| A D | design.rst | 20 iomap is a filesystem library for handling common file operations.
47 has now been extended to cover several other operations.
65 initiates operations on that basis.
83 So far only the pagecache operations need to do this.
235 heads for pagecache operations.
260 Currently, these flags are only set by pagecache operations.
265 This only needs to be set for mapped or unwritten operations.
323 operations:
396 coordinate access to different iomap operations.
401 these two file operations from clobbering each other.
[all …]
|
| /linux/Documentation/networking/ |
| A D | nfc.rst | 21 responsible for providing an interface to control operations and low-level
24 The control operations are available to userspace via generic netlink.
36 | data exchange | operations
71 The userspace interface is divided in control operations and low-level data
76 Generic netlink is used to implement the interface to the control operations.
77 The operations are composed by commands and events, all listed below:
100 All polling operations requested through one netlink socket are stopped when
|
| /linux/rust/kernel/block/ |
| A D | mq.rs | 91 mod operations; module
96 pub use operations::Operations;
|
| /linux/mm/damon/ |
| A D | Kconfig | 28 bool "Data access monitoring operations for virtual address spaces"
32 This builds the default data access monitoring operations for DAMON
36 bool "Data access monitoring operations for the physical address space"
40 This builds the default data access monitoring operations for DAMON
44 bool "Test for DAMON operations" if !KUNIT_ALL_TESTS
48 This builds the DAMON virtual addresses operations Kunit test suite.
|
| /linux/Documentation/admin-guide/perf/ |
| A D | hisi-pmu.rst | 63 This will only count the operations from core/thread 0 and 1 in this cluster.
66 operations via the tt_req parameeter in perf. The default value counts all
67 operations. tt_req is 3bits, 3'b100 represents read operations, 3'b101
68 represents write operations, 3'b110 represents atomic store operations and
69 3'b111 represents atomic non-store operations, other values are reserved::
73 This will only count the read operations in this cluster.
|
| /linux/Documentation/driver-api/ |
| A D | clk.rst | 17 gating, rate adjustment, muxing or other operations. This framework is
25 drivers/clk/clk.c. Finally there is struct clk_ops, whose operations
67 the operations defined in clk-provider.h::
175 To take advantage of your data you'll need to support valid operations
276 .disable operations. Those operations are thus not allowed to sleep,
290 The prepare lock is a mutex and is held across calls to all other operations.
291 All those operations are allowed to sleep, and calls to the corresponding API
294 This effectively divides operations in two groups from a locking perspective.
296 Drivers don't need to manually protect resources shared between the operations
304 framework functions from within its implementation of clock operations. This
[all …]
|
| A D | i2c.rst | 26 are functions to perform various I2C protocol operations; at this writing
32 Controllers that support I2C can also support most SMBus operations, but
35 operations, either using I2C primitives or by issuing SMBus commands to
36 i2c_adapter devices which don't support those I2C operations.
|
| /linux/Documentation/filesystems/spufs/ |
| A D | spufs.rst | 45 the operations supported on regular file systems. This list details the
46 supported operations and the deviations from the behaviour in the
51 All files support the access(2) and stat(2) family of operations, but
57 possible operations, e.g. read access on the wbox file.
65 data in the address space of the SPU. The possible operations on an
84 operations on an open mbox file are:
98 operations on an open ibox file are:
121 operations on an open wbox file are: write(2) If a count smaller than
143 operations on an open ``*box_stat`` file are:
173 The possible operations on an open npc, decr, decr_status,
[all …]
|
| /linux/Documentation/arch/arm/vfp/ |
| A D | release-notes.rst | 19 The operations which have been tested with this package are:
41 Other operations which have been tested by basic assembly-only tests
51 The combination operations have not been tested:
|
| /linux/Documentation/devicetree/bindings/dma/ |
| A D | mv-xor.txt | 20 - dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations
21 - dmacap,memset to indicate that the XOR channel is capable of memset operations
22 - dmacap,xor to indicate that the XOR channel is capable of xor operations
|
| A D | stericsson,dma40.yaml | 73 51: memcpy TX (to be used by the DMA driver for memcpy operations)
78 56: memcpy (to be used by the DMA driver for memcpy operations)
79 57: memcpy (to be used by the DMA driver for memcpy operations)
80 58: memcpy (to be used by the DMA driver for memcpy operations)
81 59: memcpy (to be used by the DMA driver for memcpy operations)
82 60: memcpy (to be used by the DMA driver for memcpy operations)
|
| /linux/Documentation/ABI/testing/ |
| A D | debugfs-pfo-nx-crypto | 33 The total number of AES operations submitted to the hardware.
39 The total number of SHA-256 operations submitted to the hardware.
45 The total number of SHA-512 operations submitted to the hardware.
|
| /linux/Documentation/filesystems/ |
| A D | directory-locking.rst | 6 Locking scheme used for directory operations is based on two
18 For our purposes all operations fall in 6 classes:
74 operations on directory trees, but we obviously do not have the full
77 Trees grow as we do operations; memory pressure prunes them. Normally
120 using a local one as a cache, etc. In all such cases the operations
160 It's easy to verify that operations never take a lock with rank
187 only 3 possible operations: directory removal (locks parent, then
192 if all operations had been of the "lock parent, then child" sort
199 Since all operations are on the same filesystem, there can't be
236 That concludes the proof, since the set of operations with the
[all …]
|