| /Linux-v4.19/net/dccp/ |
| D | qpolicy.c | 51 struct sk_buff *skb, *worst = NULL; in qpolicy_prio_worst_skb() local
54 if (worst == NULL || skb->priority < worst->priority) in qpolicy_prio_worst_skb()
55 worst = skb; in qpolicy_prio_worst_skb()
56 return worst; in qpolicy_prio_worst_skb()
|
| /Linux-v4.19/arch/h8300/lib/ |
| D | mulsi3.S | 9 ; 16b * 16b = 372 states (worst case)
10 ; 32b * 32b = 724 states (worst case)
|
| /Linux-v4.19/Documentation/devicetree/bindings/power/ |
| D | domain-idle-state.txt | 16 Definition: u32 value representing worst case latency in
24 Definition: u32 value representing worst case latency
|
| /Linux-v4.19/arch/x86/boot/ |
| D | header.S | 493 # The worst case at the block level is a growth of the compressed data
496 # The worst case internal to a compressed block is very hard to figure.
497 # The worst case can at least be bounded by having one bit that represents
504 # block adding an extra 32767 bytes (the worst case uncompressed block size)
505 # is sufficient, to ensure that in the worst case the decompressed data for
|
| /Linux-v4.19/arch/x86/kernel/cpu/mcheck/ |
| D | mce.c | 1105 int no_way_out, int *worst) in __mc_scan_banks() argument
1160 if (severity > *worst) { in __mc_scan_banks()
1162 *worst = severity; in __mc_scan_banks()
1190 int worst = 0; in do_machine_check() local
1263 __mc_scan_banks(&m, final, toclear, valid_banks, no_way_out, &worst); in do_machine_check()
1274 no_way_out = worst >= MCE_PANIC_SEVERITY; in do_machine_check()
1284 if (worst >= MCE_PANIC_SEVERITY && mca_cfg.tolerant < 3) { in do_machine_check()
1299 if (worst > 0) in do_machine_check()
1305 if (worst != MCE_AR_SEVERITY && !kill_it) in do_machine_check()
|
| /Linux-v4.19/Documentation/x86/x86_64/ |
| D | cpu-hotplug-spec | 18 In the worst case the user can overwrite this choice using a command line
|
| /Linux-v4.19/tools/power/cpupower/bench/ |
| D | README-BENCH | 7 - Identify worst case performance loss when doing dynamic frequency
84 will always see 50% loads and you get worst performance impact never
|
| /Linux-v4.19/Documentation/devicetree/bindings/regulator/ |
| D | vctrl.txt | 29 down in the worst case (lightest expected load).
|
| /Linux-v4.19/drivers/block/mtip32xx/ |
| D | mtip32xx.h | 179 u8 worst; member
|
| /Linux-v4.19/arch/x86/math-emu/ |
| D | README | 239 each function was tested at about 400 points. Ideal worst-case results
307 worst-case results which are better than the worst-case results given
321 the worst accuracy which was found (in bits) and the approximate value
326 instr arg range # tests 63.7 63.8 63.9 worst at arg
|
| /Linux-v4.19/Documentation/media/v4l-drivers/ |
| D | cafe_ccic.rst | 36 then worst-case-sized buffers will be allocated at module load time.
|
| /Linux-v4.19/Documentation/vm/ |
| D | zsmalloc.rst | 23 worst case, page is incompressible and is thus stored "as-is" i.e. in
|
| D | ksm.rst | 62 deduplication factor at the expense of slower worst case for rmap
|
| /Linux-v4.19/Documentation/devicetree/bindings/arm/ |
| D | idle-states.txt | 106 the worst case since it depends on the CPU operating conditions, ie caches
111 worst case wake-up latency it can incur if a CPU is allowed to enter an
284 Definition: u32 value representing worst case latency in
292 Definition: u32 value representing worst case latency
|
| /Linux-v4.19/Documentation/timers/ |
| D | timers-howto.txt | 87 worst case, fire an interrupt for your upper bound.
|
| /Linux-v4.19/arch/arm/nwfpe/ |
| D | ChangeLog | 44 * I discovered several bugs. First and worst is that the kernel
|
| /Linux-v4.19/Documentation/device-mapper/ |
| D | log-writes.txt | 25 simulate the worst case scenario with regard to power failures. Consider the
|
| /Linux-v4.19/Documentation/security/ |
| D | self-protection.rst | 13 In the worst-case scenario, we assume an unprivileged local attacker
16 but with systems in place that defend against the worst case we'll
|
| /Linux-v4.19/Documentation/ |
| D | pi-futex.txt | 25 determinism and well-bound latencies. Even in the worst-case, PI will
|
| /Linux-v4.19/Documentation/process/ |
| D | 6.Followthrough.rst | 128 is that conflicts with work being done by others turn up. In the worst
157 The worst sort of bug reports are regressions. If your patch causes a
|
| /Linux-v4.19/Documentation/powerpc/ |
| D | eeh-pci-error-recovery.txt | 97 reinitialization of the device driver. In a worst-case scenario,
105 kernel/device driver should assume the worst-case scenario, that the
|
| /Linux-v4.19/Documentation/admin-guide/mm/ |
| D | ksm.rst | 141 deduplication factor will be, but the slower the worst case
|
| /Linux-v4.19/Documentation/driver-api/usb/ |
| D | persist.rst | 24 device plugged into the port. The system must assume the worst.
|
| /Linux-v4.19/drivers/scsi/esas2r/ |
| D | atvda.h | 511 u8 worst; member
|
| /Linux-v4.19/Documentation/x86/ |
| D | intel_mpx.txt | 132 even if we clean them up aggressively. In the worst-case scenario, the
|
