Gabriele Monaco <[email protected]> writes: > Looks neat, so the idea here is that we are looking at the same events > sleep would react for, just from a different perspective, so it does > make sense to run them both together. > > You may want to set > > depends on RV_PER_TASK_MONITORS >= 3 > > in rtapp/Kconfig. Though if we plan to add more per-task monitors we may > need to find a better solution.
Yeah, perhaps some sort of list instead of the current fixed-length array. >> diff --git a/tools/verification/models/rtapp/wakeup.ltl >> b/tools/verification/models/rtapp/wakeup.ltl >> new file mode 100644 >> index 000000000000..a5d63ca0811a >> --- /dev/null >> +++ b/tools/verification/models/rtapp/wakeup.ltl >> @@ -0,0 +1,5 @@ >> +RULE = always (((RT and USER_THREAD) imply >> + (not (WOKEN_BY_LOWER_PRIO or WOKEN_BY_SOFTIRQ)) or >> ALLOWLIST)) >> + >> +ALLOWLIST = BLOCK_ON_RT_MUTEX >> + or FUTEX_LOCK_PI > > So here the events and atoms are similar to the ones in sleep, but since > we fail on the waking event, we are going to see it from the perspective > of the waker task, right? > > But are those really equivalent? Why do we do RT and USER_THREAD here > while there is a much more nuanced set of conditions in sleep? > > If I understand it correctly, sleep can monitor some kernel threads but > this monitor does not, is there a reason for that? Are we just not > interested in the waker for kernel threads? Urgh, initially I had a patch which drops kernel threads in the sleep monitor, but finally I decided to drop that patch. This is the leftover of that. You are right that we should be consistent and consider kernel threads here as well. > I'm not sure if there is any better terminology, but "waking" task makes > me think of the task that is about to be woken, though it can mean also > that task that is waking another (what you probably mean here). > > What about using the waker/wakee terminology? waker/wakee would be clearer. > I see the kernel (events/sched.h) uses waking as well, but it says > waking context (which a bit clearer to me than waking task). > May be worth running it through an LLM which can produce more > English-native unambiguous wording, or maybe I'm just flipping.. > > Also please document it in Documentation/trace/rv/monitor_rtapp.rst Right, thanks for the reminder. Nam
