| /linux-6.15/net/dccp/ |
| H A D | qpolicy.c | 48 struct sk_buff *skb, *worst = NULL; in qpolicy_prio_worst_skb() local
51 if (worst == NULL || skb->priority < worst->priority) in qpolicy_prio_worst_skb()
52 worst = skb; in qpolicy_prio_worst_skb()
53 return worst; in qpolicy_prio_worst_skb()
|
| /linux-6.15/arch/x86/boot/ |
| H A D | header.S | 444 # The worst case at the block level is a growth of the compressed data
447 # The worst case internal to a compressed block is very hard to figure.
448 # The worst case can at least be bounded by having one bit that represents
455 # block adding an extra 32767 bytes (the worst case uncompressed block size)
456 # is sufficient, to ensure that in the worst case the decompressed data for
|
| /linux-6.15/Documentation/devicetree/bindings/power/ |
| H A D | domain-idle-state.yaml | 33 The worst case latency in microseconds required to enter the idle
39 The worst case latency in microseconds required to exit the idle
|
| /linux-6.15/Documentation/arch/x86/x86_64/ |
| H A D | cpu-hotplug-spec.rst | 21 In the worst case the user can overwrite this choice using a command line
|
| /linux-6.15/tools/power/cpupower/bench/ |
| H A 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-6.15/arch/x86/kernel/cpu/mce/ |
| H A D | core.c | 1319 unsigned long *valid_banks, int no_way_out, int *worst) in __mc_scan_banks() argument
1382 if (severity > *worst) { in __mc_scan_banks()
1384 *worst = severity; in __mc_scan_banks()
1516 int worst = 0, order, no_way_out, kill_current_task, lmce, taint = 0; in do_machine_check() local
1600 taint = __mc_scan_banks(&err, regs, final, toclear, valid_banks, no_way_out, &worst); in do_machine_check()
1612 no_way_out = worst >= MCE_PANIC_SEVERITY; in do_machine_check()
1626 if (worst >= MCE_PANIC_SEVERITY) { in do_machine_check()
1642 if (worst != MCE_AR_SEVERITY && !kill_current_task) in do_machine_check()
|
| /linux-6.15/tools/testing/selftests/net/packetdrill/ |
| H A D | tcp_zerocopy_maxfrags.pkt | 17 // This test generates a worst case packet with each frag storing
|
| /linux-6.15/Documentation/devicetree/bindings/regulator/ |
| H A D | vctrl-regulator.yaml | 35 worst case (lightest expected load). Specified in uV / us (like
|
| /linux-6.15/drivers/block/mtip32xx/ |
| H A D | mtip32xx.h | 165 u8 worst; member
|
| /linux-6.15/Documentation/hwmon/ |
| H A D | stpddc60.rst | 41 writing to those limits since in the worst case the commanded output voltage
|
| /linux-6.15/arch/x86/math-emu/ |
| H A 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-6.15/Documentation/admin-guide/media/ |
| H A D | cafe_ccic.rst | 38 then worst-case-sized buffers will be allocated at module load time.
|
| /linux-6.15/Documentation/userspace-api/media/v4l/ |
| H A D | pixfmt-v4l2-mplane.rst | 30 codec to support the worst-case compression scenario.
|
| /linux-6.15/Documentation/tools/rtla/ |
| H A D | rtla-hwnoise.rst | 72 for the application. In the worst single period, the CPU caused *4 us* of
|
| /linux-6.15/Documentation/mm/ |
| H A D | ksm.rst | 60 deduplication factor at the expense of slower worst case for rmap
|
| /linux-6.15/Documentation/ABI/testing/ |
| H A D | sysfs-platform-dptf | 52 (RO) Shows the rest (outside of SoC) of worst-case platform power.
|
| /linux-6.15/arch/arm/nwfpe/ |
| H A D | ChangeLog | 44 * I discovered several bugs. First and worst is that the kernel
|
| /linux-6.15/Documentation/arch/arm64/ |
| H A D | memory.rst | 75 the "worst" case.
|
| /linux-6.15/arch/arm64/boot/dts/rockchip/ |
| H A D | rk3588-jaguar-pre-ict-tester.dtso | 106 * the worst case scenario and the pass scenario expect
|
| /linux-6.15/Documentation/devicetree/bindings/display/panel/ |
| H A D | panel-edp.yaml | 29 list eDP panels. We solve that here with two tricks. The "worst case"
|
| /linux-6.15/Documentation/admin-guide/device-mapper/ |
| H A D | log-writes.rst | 26 simulate the worst case scenario with regard to power failures. Consider the
|
| /linux-6.15/Documentation/security/ |
| H A 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-6.15/Documentation/locking/ |
| H A D | pi-futex.rst | 25 determinism and well-bound latencies. Even in the worst-case, PI will
|
| /linux-6.15/Documentation/arch/powerpc/ |
| H A D | eeh-pci-error-recovery.rst | 97 reinitialization of the device driver. In a worst-case scenario,
105 kernel/device driver should assume the worst-case scenario, that the
|
| /linux-6.15/Documentation/process/ |
| H A D | 6.Followthrough.rst | 135 is that conflicts with work being done by others turn up. In the worst
164 The worst sort of bug reports are regressions. If your patch causes a
|