Searched refs:worst (Results 1 – 24 of 24) sorted by relevance
| /linux-2.6.39/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-2.6.39/Documentation/x86/x86_64/ |
| D | cpu-hotplug-spec | 18 In the worst case the user can overwrite this choice using a command line
|
| /linux-2.6.39/arch/x86/kernel/cpu/mcheck/ |
| D | mce.c | 924 int worst = 0; in do_machine_check() local
1043 if (severity > worst) { in do_machine_check()
1045 worst = severity; in do_machine_check()
1057 no_way_out = worst >= MCE_PANIC_SEVERITY; in do_machine_check()
1082 if (worst > 0) in do_machine_check()
|
| /linux-2.6.39/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-2.6.39/Documentation/video4linux/ |
| D | cafe_ccic | 23 then worst-case-sized buffers will be allocated at module load time.
|
| D | ibmcam.txt | 231 an approximate setting (in terms of "worst" ... "best")
|
| /linux-2.6.39/Documentation/timers/ |
| D | timers-howto.txt | 87 worst case, fire an interrupt for your upper bound.
|
| /linux-2.6.39/arch/arm/nwfpe/ |
| D | ChangeLog | 44 * I discovered several bugs. First and worst is that the kernel
|
| /linux-2.6.39/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 | 563 do not violate those constraints. In the worst case such a violation can
|
| /linux-2.6.39/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-2.6.39/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-2.6.39/Documentation/arm/msm/ |
| D | gpiomux.txt | 26 is meaningless at best, and deceptive at worst. In addition, using the
|
| /linux-2.6.39/Documentation/usb/ |
| D | persist.txt | 21 device plugged into the port. The system must assume the worst.
|
| /linux-2.6.39/Documentation/trace/ |
| D | ftrace.txt | 906 Real-Time environments are interested in the worst case latency.
911 to record the worst case wakeups of RT tasks. Non-RT tasks are
912 not recorded because the tracer only records one worst case and
914 worst case latency of RT tasks.
|
| /linux-2.6.39/arch/m68k/fpsp040/ |
| D | round.S | 284 | Note that both routines have been optimized (for the worst case) and
|
| /linux-2.6.39/arch/m68k/ifpsp060/src/ |
| D | ilsp.S | 360 # quotient will be at worst 1 too large.
|
| /linux-2.6.39/Documentation/crypto/ |
| D | descore-readme.txt | 191 the (worst-case) cost of my NOT doing endedness-specific optimizations
|
| /linux-2.6.39/Documentation/PCI/ |
| D | pci-error-recovery.txt | 359 The device driver should, at this point, assume the worst. It should
|
| /linux-2.6.39/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
|
| D | ntfs.txt | 569 the side but they should not cause data corruption. In the worst
|
| /linux-2.6.39/Documentation/scsi/ |
| D | aic7xxx_old.txt | 402 perfect or highly robust. If you mess the line up, the worst that
|
| /linux-2.6.39/Documentation/vm/ |
| D | unevictable-lru.txt | 337 In the worst case, this will result in a page mapped in a VM_LOCKED VMA
|