| /linux-4.1.27/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.1.27/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.1.27/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.1.27/drivers/block/mtip32xx/ |
| D | mtip32xx.h | 172 u8 worst; member
|
| /linux-4.1.27/arch/x86/kernel/cpu/mcheck/ |
| D | mce.c | 1031 int worst = 0; in do_machine_check() local
1145 if (severity > worst) { in do_machine_check()
1147 worst = severity; in do_machine_check()
1162 no_way_out = worst >= MCE_PANIC_SEVERITY; in do_machine_check()
1173 if (worst == MCE_AR_SEVERITY) { in do_machine_check()
1182 if (worst > 0) in do_machine_check()
|
| /linux-4.1.27/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.1.27/Documentation/video4linux/ |
| D | cafe_ccic | 23 then worst-case-sized buffers will be allocated at module load time.
|
| /linux-4.1.27/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.1.27/drivers/staging/lustre/lustre/ptlrpc/ |
| D | lproc_ptlrpc.c | 1003 unsigned int worst; in ptlrpc_lprocfs_timeouts_seq_show() local
1014 worst = svcpt->scp_at_estimate.at_worst_ever; in ptlrpc_lprocfs_timeouts_seq_show()
1020 cur, worst, worstt, DHMS_VARS(&ts)); in ptlrpc_lprocfs_timeouts_seq_show()
|
| /linux-4.1.27/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.1.27/drivers/staging/lustre/lustre/obdclass/ |
| D | lprocfs_status.c | 876 unsigned int cur, worst; in lprocfs_rd_timeouts() local
893 worst = imp->imp_at.iat_net_latency.at_worst_ever; in lprocfs_rd_timeouts()
897 "network", cur, worst, worstt, DHMS_VARS(&ts)); in lprocfs_rd_timeouts()
904 worst = imp->imp_at.iat_service_estimate[i].at_worst_ever; in lprocfs_rd_timeouts()
909 cur, worst, worstt, DHMS_VARS(&ts)); in lprocfs_rd_timeouts()
|
| /linux-4.1.27/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.1.27/arch/arm/nwfpe/ |
| D | ChangeLog | 44 * I discovered several bugs. First and worst is that the kernel
|
| /linux-4.1.27/Documentation/device-mapper/ |
| D | log-writes.txt | 25 simulate the worst case scenario with regard to power failures. Consider the
|
| /linux-4.1.27/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 | 582 do not violate those constraints. In the worst case such a violation can
|
| /linux-4.1.27/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.1.27/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.1.27/Documentation/usb/ |
| D | persist.txt | 21 device plugged into the port. The system must assume the worst.
|
| /linux-4.1.27/drivers/scsi/esas2r/ |
| D | atvda.h | 511 u8 worst; member
|
| /linux-4.1.27/Documentation/x86/ |
| D | intel_mpx.txt | 132 even if we clean them up aggressively. In the worst-case scenario, the
|
| /linux-4.1.27/arch/m68k/fpsp040/ |
| D | round.S | 284 | Note that both routines have been optimized (for the worst case) and
|
| /linux-4.1.27/arch/m68k/ifpsp060/src/ |
| D | ilsp.S | 360 # quotient will be at worst 1 too large.
|
| /linux-4.1.27/Documentation/crypto/ |
| D | descore-readme.txt | 191 the (worst-case) cost of my NOT doing endedness-specific optimizations
|
| /linux-4.1.27/Documentation/trace/ |
| D | ftrace.txt | 1433 Real-Time environments are interested in the worst case latency.
1438 to record the worst case wakeups of RT tasks. Non-RT tasks are
1439 not recorded because the tracer only records one worst case and
1441 worst case latency of RT tasks (just run the normal wakeup
|
| /linux-4.1.27/Documentation/PCI/ |
| D | pci-error-recovery.txt | 359 The device driver should, at this point, assume the worst. It should
|
| /linux-4.1.27/Documentation/scheduler/ |
| D | sched-deadline.txt | 296 worst-case delay respect to the "deadline" parameter. If "deadline" = "period"
|
| /linux-4.1.27/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.1.27/init/ |
| D | Kconfig | 879 hotplugging making the compuation optimal for the the worst case
|