Searched full:worst (Results 1 – 25 of 39) sorted by relevance
12
| /Documentation/devicetree/bindings/power/ |
| D | domain-idle-state.yaml | 32 The worst case latency in microseconds required to enter the idle
38 The worst case latency in microseconds required to exit the idle
|
| /Documentation/x86/x86_64/ |
| D | cpu-hotplug-spec.rst | 21 In the worst case the user can overwrite this choice using a command line
|
| /Documentation/usb/ |
| D | dwc3.rst | 23 usb_ep_disable(). Worst case are 32 interrupts, the lower limit is two
|
| /Documentation/devicetree/bindings/regulator/ |
| D | vctrl.txt | 29 down in the worst case (lightest expected load).
|
| /Documentation/admin-guide/media/ |
| D | cafe_ccic.rst | 38 then worst-case-sized buffers will be allocated at module load time.
|
| /Documentation/vm/ |
| D | zsmalloc.rst | 23 worst case, page is incompressible and is thus stored "as-is" i.e. in
|
| D | ksm.rst | 62 deduplication factor at the expense of slower worst case for rmap
|
| /Documentation/devicetree/bindings/arm/ |
| D | idle-states.yaml | 87 entry-latency: Worst case latency required to enter the idle state. The
114 the worst case since it depends on the CPU operating conditions, i.e. caches
119 worst case wake-up latency it can incur if a CPU is allowed to enter an
288 Worst case latency in microseconds required to enter the idle state.
292 Worst case latency in microseconds required to exit the idle state.
|
| /Documentation/userspace-api/media/v4l/ |
| D | pixfmt-v4l2-mplane.rst | 30 codec to support the worst-case compression scenario.
|
| D | pixfmt-v4l2.rst | 95 number of bytes required by the codec to support the worst-case
|
| /Documentation/hwmon/ |
| D | max16065.rst | 89 power loss, board resets, and/or Flash corruption. Worst case, your board may
|
| D | zl6100.rst | 135 and/or Flash corruption. Worst case, your board may turn into a brick.
|
| /Documentation/timers/ |
| D | timers-howto.rst | 94 worst case, fire an interrupt for your upper bound.
|
| /Documentation/ABI/testing/ |
| D | sysfs-platform-dptf | 52 (RO) Shows the rest (outside of SoC) of worst-case platform power.
|
| /Documentation/process/ |
| D | 6.Followthrough.rst | 128 is that conflicts with work being done by others turn up. In the worst
157 The worst sort of bug reports are regressions. If your patch causes a
|
| /Documentation/locking/ |
| D | pi-futex.rst | 25 determinism and well-bound latencies. Even in the worst-case, PI will
|
| /Documentation/admin-guide/device-mapper/ |
| D | log-writes.rst | 26 simulate the worst case scenario with regard to power failures. Consider the
|
| /Documentation/security/ |
| 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
|
| /Documentation/powerpc/ |
| 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
|
| /Documentation/admin-guide/mm/ |
| D | ksm.rst | 141 deduplication factor will be, but the slower the worst case
|
| /Documentation/driver-api/usb/ |
| D | persist.rst | 24 device plugged into the port. The system must assume the worst.
|
| /Documentation/admin-guide/laptops/ |
| D | laptop-mode.rst | 126 comfortable with. Worst case, it's possible that you could lose this
241 # comfortable with. Worst case, it's possible that you could lose this
355 # comfortable with. Worst case, it's possible that you could lose this
|
| /Documentation/arm64/ |
| D | memory.rst | 147 the "worst" case.
|
| /Documentation/maintainer/ |
| D | rebasing-and-merging.rst | 45 There are a few rules of thumb that can help developers to avoid the worst
|
| /Documentation/scheduler/ |
| D | sched-deadline.rst | 332 time max{c_j} is called "Worst Case Execution Time" (WCET) for the task.
425 arbitrarily small worst case execution time (indicated as "e" here) and a
641 worst-case delay respect to the "deadline" parameter. If "deadline" = "period"
|
12