Hi Tommaso,

On Fri, 12 Sep 2025 07:38:29 +0200, Tommaso Cucinotta [off-list ref] wrote:

The SCHED_DEADLINE scheduler allows reading the statically configured
run-time, deadline, and period parameters through the sched_getattr()
system call. However, there is no immediate way to access, from user space,
the current parameters used within the scheduler: the instantaneous runtime
left in the current cycle, as well as the current absolute deadline.

The `flags' sched_getattr() parameter, so far mandated to contain zero,
now supports the SCHED_GETATTR_FLAG_DL_DYNAMIC=1 flag, to request
retrieval of the leftover runtime and absolute deadline, converted to a
CLOCK_MONOTONIC reference, instead of the statically configured parameters.

This feature is useful for adaptive SCHED_DEADLINE tasks that need to
modify their behavior depending on whether or not there is enough runtime
left in the current period, and/or what is the current absolute deadline.

Notes:
- before returning the instantaneous parameters, the runtime is updated;
- the abs deadline is returned shifted from rq_clock() to ktime_get_ns(),
  in CLOCK_MONOTONIC reference; this causes multiple invocations from the
  same period to return values that may differ for a few ns (showing some
  small drift), albeit the deadline doesn't move, in rq_clock() reference;
- the abs deadline value returned to user-space, as unsigned 64-bit value,
  can represent nearly 585 years since boot time;
- setting flags=0 provides the old behavior (retrieve static parameters).

See also the notes from discussion held at OSPM 2025 on the topic
"Making user space aware of current deadline-scheduler parameters".

Signed-off-by: Tommaso Cucinotta <redacted>
...

I tested your patch and I can confirm I could retrieve the remaining runtime and
absolute deadline values via sched_gettattr() as you mentioned in your cover
letter. I'm involved in a project where the deadline scheduler is used in
critical realtime applications, which are monitored in order to let the system
react in case of misbehaviours, for instance if the applications overrun their
WCET or miss their expected deadlines.

On top of your reasons explained at OSPM 2025, I think this patch could be also
useful in regards of monitoring as it would let userspace retrieve a more
accurate runtime value compared to the typical estimation calculated via the
clock_gettime(CLOCK_THREAD_CPUTIME_ID). To my understanding, the runtime_left
retrieved with sched_gettattr() is also more representative of the actual task
remaining budget when the runtime is scaled in dl_scaled_delta_exec() to
calculate the time invariant task utilization [1] for energy-aware scheduling
[2]. Moreover, this patch would allow the application to determine deadline
misses.

Tested-by: Matteo Martelli <redacted>

Best regards,
Matteo Martelli

[1]: https://www.kernel.org/doc/html/v6.17/scheduler/sched-capacity.html#frequency-invariance
[2]: https://www.kernel.org/doc/html/v6.17/scheduler/sched-deadline.html#energy-aware-scheduling