Searched full:reorder (Results 1 – 24 of 24) sorted by relevance
| /Documentation/devicetree/bindings/media/ |
| D | fsl-vdoa.txt | 5 is to reorder video data from the macroblock tiled order produced by the CODA
|
| /Documentation/networking/ |
| D | tls-offload.rst | 264 A small amount of RX reorder events may not require a full resynchronization.
268 .. kernel-figure:: tls-offload-reorder-good.svg
269 :alt: reorder of non-header segment
272 Reorder of non-header segment
293 .. kernel-figure:: tls-offload-reorder-bad.svg
294 :alt: reorder of header segment
297 Reorder of segment with a TLS header
493 Ingress reorder
|
| D | l2tp.rst | 378 REORDERTO reorder timeout (in millisecs). If 0, don't try to reorder.
|
| D | snmp_counter.rst | 605 The reorder packet is detected by fast recovery. It would only be used
616 The reorder packet is detected when a hole is filled. E.g., assume the
626 The reorder packet detected by SACK. The SACK has two methods to
627 detect reorder: (1) DSACK is received by the sender. It means the
|
| D | timestamping.rst | 383 itself does not reorder the segments. The stack indeed tries to avoid
|
| D | bonding.rst | 2441 coalescing), and a "many to many" topology will reorder at a
|
| /Documentation/devicetree/bindings/interrupt-controller/ |
| D | sifive,plic-1.0.0.yaml | 34 needs to know the trigger type, so it can reorder the interrupt flow to avoid
|
| /Documentation/RCU/ |
| D | checklist.rst | 122 CPUs' tendency to reorder memory references. One must
148 Please note that compilers can also reorder code, and
469 and the compiler to freely reorder code into and out of RCU
|
| D | rcu_dereference.rst | 141 to reorder the non-existent subsequent dereferences.
210 value-speculation optimizations reorder operations by design.
|
| /Documentation/driver-api/ |
| D | device-io.rst | 69 compiler is not permitted to reorder the I/O sequence. When the ordering
310 * No reordering - The CPU may not reorder accesses to this memory mapping with
337 * The CPU may reorder operations as long as the result is consistent from the
|
| /Documentation/ |
| D | memory-barriers.txt | 550 hardware[*] will not reorder the memory accesses. CPU cache coherency
731 b = 1; /* BUG: Compiler and CPU can both reorder!!! */
764 'b', which means that the CPU is within its rights to reorder them:
868 compiler cannot reorder volatile accesses and also cannot reorder
1560 (*) The compiler is within its rights to reorder loads and stores
1562 rights to reorder loads to the same variable. This means that
1683 (*) The compiler is within its rights to reorder memory accesses unless
1832 which may then reorder things however it wishes.
2486 efficient to reorder, combine or merge accesses - something that would cause
2687 Similarly, it has to be assumed that compiler might reorder the instruction
[all …]
|
| /Documentation/core-api/ |
| D | unaligned-memory-access.rst | 115 that you could reorder the fields in the structure in order to place fields
|
| D | dma-api-howto.rst | 328 proper memory barriers. The CPU may reorder stores to
|
| /Documentation/admin-guide/device-mapper/ |
| D | vdo.rst | 397 reorder I/O requests for performance benefit, but also that each I/O
|
| /Documentation/netlink/specs/ |
| D | tc.yaml | 386 name: tc-netem-reorder
3240 name: reorder
3242 struct: tc-netem-reorder
|
| D | rt_link.yaml | 758 - reorder-hdr
|
| /Documentation/filesystems/ |
| D | ubifs-authentication.rst | 359 Since the hash also includes the reference nodes an attacker cannot reorder or
|
| D | porting.rst | 326 and vmtruncate, and the reorder the vmtruncate + foofs_vmtruncate sequence to
|
| /Documentation/scsi/ |
| D | ChangeLog.megaraid | 428 iii. Module compilation reorder in Makefile so that unresolved symbols do
|
| D | ChangeLog.lpfc | 815 * Reorder functions in lpfc_els.c to remove need for prototypes.
|
| /Documentation/block/ |
| D | bfq-iosched.rst | 403 devices reorder internally-queued requests, which may trivially break
|
| /Documentation/RCU/Design/Requirements/ |
| D | Requirements.rst | 225 their rights to reorder this code as follows:
742 | Can't the compiler also reorder this code? |
1009 #. Both the compiler and the CPU can reorder memory accesses. Where it
2018 reorder a get_user() invocation into an RCU read-side critical section.
|
| /Documentation/kernel-hacking/ |
| D | locking.rst | 1087 compilers and modern CPUs can both reorder instructions unless told
|
| /Documentation/translations/ko_KR/ |
| D | memory-barriers.txt | 740 b = 1; /* BUG: Compiler and CPU can both reorder!!! */
|