@@ -766,9 +767,11 @@ struct scx_rq {
unsigned long ops_qseq;
u64 extra_enq_flags; /* see move_task_to_local_dsq() */
u32 nr_running;
- u32 flags;
u32 cpuperf_target; /* [0, SCHED_CAPACITY_SCALE] */
bool cpu_released;
+ u32 flags;
+ u64 clock; /* current per-rq clock -- see scx_bpf_now_ns() */
+ u64 prev_clock; /* previous per-rq clock -- see scx_bpf_now_ns() */
Since we're reordering this struct, we may want to move cpu_released all
the way to the bottom to get rid of the 3-bytes hole (and still have
flags, clock and prev_clock in the same cacheline).
Nit, this is just personal preference (feel free to ignore it):That's prettier. I will change it as you suggested.
if (!scx_enabled())
return;
rq->scx.prev_clock = rq->scx.clock;
rq->scx.clock = clock;
rq->scx.flags |= SCX_RQ_CLK_VALID;
I'm wondering if we need to invalidate the clock on all rqs when we call
scx_ops_enable() to prevent getting stale information from a previous
scx scheduler.
Probably it's not an issue, since scx_ops_disable_workfn() should make
sure that all tasks are going through rq_unpin_lock() before unloading
the current scheduler, maybe it could be helpful to add comment about
this scenario in scx_bpf_now_ns() (PATCH 4/6)?