| /linux-4.4.14/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-4.4.14/arch/h8300/lib/ |
| D | mulsi3.S | 8 ; 16b * 16b = 372 states (worst case)
9 ; 32b * 32b = 724 states (worst case)
|
| /linux-4.4.14/Documentation/x86/x86_64/ |
| D | cpu-hotplug-spec | 18 In the worst case the user can overwrite this choice using a command line
|
| /linux-4.4.14/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-4.4.14/arch/x86/kernel/cpu/mcheck/ |
| D | mce.c | 978 int worst = 0; in do_machine_check() local
1107 if (severity > worst) { in do_machine_check()
1109 worst = severity; in do_machine_check()
1125 no_way_out = worst >= MCE_PANIC_SEVERITY; in do_machine_check()
1131 if (worst >= MCE_PANIC_SEVERITY && mca_cfg.tolerant < 3) in do_machine_check()
1145 if (worst == MCE_AR_SEVERITY) { in do_machine_check()
1154 if (worst > 0) in do_machine_check()
|
| /linux-4.4.14/drivers/block/mtip32xx/ |
| D | mtip32xx.h | 178 u8 worst; member
|
| /linux-4.4.14/drivers/staging/lustre/lustre/obdclass/ |
| D | lprocfs_status.c | 820 unsigned int cur, worst; in lprocfs_rd_timeouts() local
840 worst = imp->imp_at.iat_net_latency.at_worst_ever; in lprocfs_rd_timeouts()
844 "network", cur, worst, (s64)worstt, DHMS_VARS(&ts)); in lprocfs_rd_timeouts()
851 worst = imp->imp_at.iat_service_estimate[i].at_worst_ever; in lprocfs_rd_timeouts()
856 cur, worst, (s64)worstt, DHMS_VARS(&ts)); in lprocfs_rd_timeouts()
|
| /linux-4.4.14/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-4.4.14/Documentation/video4linux/ |
| D | cafe_ccic | 23 then worst-case-sized buffers will be allocated at module load time.
|
| /linux-4.4.14/Documentation/vm/ |
| D | zsmalloc.txt | 20 worst case, page is incompressible and is thus stored "as-is" i.e. in
|
| D | cleancache.txt | 203 overhead is negligible even in worst case workloads. Basically
|
| D | unevictable-lru.txt | 334 In the worst case, this will result in a page mapped in a VM_LOCKED VMA
|
| /linux-4.4.14/drivers/staging/lustre/lustre/ptlrpc/ |
| D | lproc_ptlrpc.c | 969 unsigned int worst; in ptlrpc_lprocfs_timeouts_seq_show() local
980 worst = svcpt->scp_at_estimate.at_worst_ever; in ptlrpc_lprocfs_timeouts_seq_show()
986 cur, worst, (s64)worstt, DHMS_VARS(&ts)); in ptlrpc_lprocfs_timeouts_seq_show()
|
| /linux-4.4.14/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-4.4.14/Documentation/timers/ |
| D | timers-howto.txt | 87 worst case, fire an interrupt for your upper bound.
|
| D | NO_HZ.txt | 111 it allows them to improve their worst-case response times by the maximum
|
| /linux-4.4.14/arch/arm/nwfpe/ |
| D | ChangeLog | 44 * I discovered several bugs. First and worst is that the kernel
|
| /linux-4.4.14/Documentation/device-mapper/ |
| D | log-writes.txt | 25 simulate the worst case scenario with regard to power failures. Consider the
|
| /linux-4.4.14/Documentation/ |
| D | pi-futex.txt | 24 determinism and well-bound latencies. Even in the worst-case, PI will
|
| D | rbtree.txt | 17 worst case performance for insertion and deletion (at most two rotations and
|
| D | DMA-API.txt | 576 do not violate those constraints. In the worst case such a violation can
|
| /linux-4.4.14/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-4.4.14/Documentation/development-process/ |
| D | 6.Followthrough | 123 is that conflicts with work being done by others turn up. In the worst
152 The worst sort of bug reports are regressions. If your patch causes a
|
| /linux-4.4.14/Documentation/usb/ |
| D | persist.txt | 21 device plugged into the port. The system must assume the worst.
|
| /linux-4.4.14/drivers/scsi/esas2r/ |
| D | atvda.h | 511 u8 worst; member
|
| /linux-4.4.14/Documentation/x86/ |
| D | intel_mpx.txt | 132 even if we clean them up aggressively. In the worst-case scenario, the
|
| /linux-4.4.14/Documentation/scheduler/ |
| D | sched-deadline.txt | 229 arbitrarily small worst case execution time (indicated as "e" here) and a
420 worst-case delay respect to the "deadline" parameter. If "deadline" = "period"
|
| /linux-4.4.14/arch/m68k/fpsp040/ |
| D | round.S | 284 | Note that both routines have been optimized (for the worst case) and
|
| /linux-4.4.14/Documentation/crypto/ |
| D | descore-readme.txt | 191 the (worst-case) cost of my NOT doing endedness-specific optimizations
|
| /linux-4.4.14/arch/m68k/ifpsp060/src/ |
| D | ilsp.S | 360 # quotient will be at worst 1 too large.
|
| /linux-4.4.14/Documentation/trace/ |
| D | ftrace.txt | 1446 Real-Time environments are interested in the worst case latency.
1451 to record the worst case wakeups of RT tasks. Non-RT tasks are
1452 not recorded because the tracer only records one worst case and
1454 worst case latency of RT tasks (just run the normal wakeup
|
| /linux-4.4.14/Documentation/PCI/ |
| D | pci-error-recovery.txt | 359 The device driver should, at this point, assume the worst. It should
|
| /linux-4.4.14/Documentation/filesystems/ |
| D | xfs-delayed-logging-design.txt | 308 bigger with a lot more items in it. The worst case effect of this is that we
485 A typical transaction reserves enough space in the log for the worst case space
|
| /linux-4.4.14/init/ |
| D | Kconfig | 858 hotplugging making the compuation optimal for the the worst case
|