Lines Matching full:time

1 Real-time application monitors
11 Real-time applications may have design flaws such that they experience
12 unexpected latency and fail to meet their time requirements. Often, these flaws
15   - Page faults: A real-time thread may access memory that does not have a
18     action. This causes significant delays to the real-time thread
19   - Priority inversion: A real-time thread blocks waiting for a lower-priority
20     thread. This causes the real-time thread to effectively take on the
21     scheduling priority of the lower-priority thread. For example, the real-time
23     non-pi-mutex, but the mutex is currently owned by a non-real-time thread.
26 reasons for unexpected latency with real-time applications. It is a container of
32 The `pagefault` monitor reports real-time tasks raising page faults. Its
40 This monitor may have false negatives because the pages used by the real-time
50 The `sleep` monitor reports real-time threads sleeping in a manner that may
51 cause undesirable latency. Real-time applications should only put a real-time
54   - Cyclic work: real-time thread sleeps waiting for the next cycle. For this
56     (to avoid time drift) and `CLOCK_MONOTONIC` (to avoid the clock being
57     changed). No other method is safe for real-time. For example, threads
58     waiting for timerfd can be woken by softirq which provides no real-time
60   - Real-time thread waiting for something to happen (e.g. another thread
66     variables as safe for real-time. As an alternative, the librtpi library
68     real-time applications in Linux.
71 real-time-safe. Namely, one of:
79   - Real-time thread is blocked by a non-real-time thread (e.g. due to
82   - Time-critical work waits for something which is not safe for real-time (e.g.
84   - The work executed by the real-time thread does not need to run at real-time
85     priority at all.  This is not a problem for the real-time thread itself, but
86     it is potentially taking the CPU away from other important real-time work.
88 Application developers may purposely choose to have their real-time application
89 sleep in a way that is not safe for real-time. It is debatable whether that is a
121     as valid real-time sleeping reasons. Therefore sleeping reason is not
123   - `KTHREAD_SHOULD_STOP`: a non-real-time thread may stop a real-time kernel
125     wakeup is safe for real-time.
129     the rt_mutex's waiter. Consequently, the monitor may see a real-time-unsafe
130     wakeup (e.g. non-real-time task waking real-time task). This is actually
131     real-time-safe because preemption is disabled for the duration.