Commit 84b1a0ea0b7c
("sched_ext: Implement scx_bpf_dsq_reenq() for user DSQs")
introduced the possibility of ops.enqueue() being called multiple times
in a row for the same task without intervening calls to ops.dequeue().
Document this behavior as it may be surprising to some.
Acked-by: Andrea Righi <arighi@nvidia.com>
Acked-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
Signed-off-by: Kuba Piecuch <jpiecuch@google.com>
---
Changes in v2:
- Removed redundant line from commit description (Cheng-Yang)
Documentation/scheduler/sched-ext.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/scheduler/sched-ext.rst b/Documentation/scheduler/sched-ext.rst
index 03d595d178ea..fba09aa1cd4e 100644
--- a/Documentation/scheduler/sched-ext.rst
+++ b/Documentation/scheduler/sched-ext.rst
@@ -339,6 +339,11 @@ The following briefly shows how a waking task is scheduled and executed.
leaves (e.g., when ``ops.dispatch()`` moves it to a terminal DSQ, or
on property change / sleep).
+ Note that ``ops.enqueue()`` can be called multiple times in a row without
+ an intervening call to ``ops.dequeue()``. This can happen, for example,
+ when a task on a user-created DSQ is re-enqueued using
+ ``scx_bpf_dsq_reenq()``. The task stays in BPF custody the entire time.
+
When a task leaves BPF scheduler custody, ``ops.dequeue()`` is invoked.
The dequeue can happen for different reasons, distinguished by flags:
--
2.54.0.rc1.555.g9c883467ad-goog