Home
last modified time | relevance | path

Searched refs:worst (Results 1 – 25 of 48) sorted by relevance

12

/linux/net/dccp/
H A Dqpolicy.c48 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/arch/x86/boot/
H A Dheader.S444 # 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/tools/power/cpupower/bench/
H A DREADME-BENCH7 - Identify worst case performance loss when doing dynamic frequency
84 will always see 50% loads and you get worst performance impact never
/linux/Documentation/arch/x86/x86_64/
H A Dcpu-hotplug-spec.rst21 In the worst case the user can overwrite this choice using a command line
/linux/tools/testing/selftests/net/packetdrill/
H A Dtcp_zerocopy_maxfrags.pkt17 // This test generates a worst case packet with each frag storing
/linux/drivers/block/mtip32xx/
H A Dmtip32xx.h165 u8 worst; member
/linux/arch/x86/math-emu/
H A DREADME239 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/Documentation/hwmon/
H A Dstpddc60.rst41 writing to those limits since in the worst case the commanded output voltage
/linux/Documentation/admin-guide/media/
H A Dcafe_ccic.rst38 then worst-case-sized buffers will be allocated at module load time.
/linux/Documentation/userspace-api/media/v4l/
H A Dpixfmt-v4l2-mplane.rst30 codec to support the worst-case compression scenario.
H A Dpixfmt-v4l2.rst95 number of bytes required by the codec to support the worst-case
/linux/Documentation/tools/rtla/
H A Drtla-hwnoise.rst72 for the application. In the worst single period, the CPU caused *4 us* of
/linux/Documentation/mm/
H A Dksm.rst60 deduplication factor at the expense of slower worst case for rmap
H A Dzsmalloc.rst21 worst case, page is incompressible and is thus stored "as-is" i.e. in
/linux/Documentation/ABI/testing/
H A Dsysfs-platform-dptf52 (RO) Shows the rest (outside of SoC) of worst-case platform power.
/linux/arch/arm/nwfpe/
H A DChangeLog44 * I discovered several bugs. First and worst is that the kernel
/linux/Documentation/admin-guide/device-mapper/
H A Dlog-writes.rst26 simulate the worst case scenario with regard to power failures. Consider the
/linux/Documentation/security/
H A Dself-protection.rst13 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/Documentation/arch/powerpc/
H A Deeh-pci-error-recovery.rst97 reinitialization of the device driver. In a worst-case scenario,
105 kernel/device driver should assume the worst-case scenario, that the
/linux/Documentation/process/
H A D6.Followthrough.rst135 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
/linux/Documentation/locking/
H A Dpi-futex.rst25 determinism and well-bound latencies. Even in the worst-case, PI will
/linux/Documentation/driver-api/usb/
H A Dpersist.rst24 device plugged into the port. The system must assume the worst.
/linux/drivers/scsi/esas2r/
H A Datvda.h511 u8 worst; member
/linux/Documentation/core-api/
H A Dmaple_tree.rst202 allocate the worst-case number of needed nodes to insert the provided number of
/linux/Documentation/scheduler/
H A Dsched-bwc.rst58 At the same time, we can say that the worst case deadline miss, will be

12