On Mon, Dec 09, 2024 at 03:15:29PM +0900, Changwoo Min wrote:I will update it as Tejun suggested.
+ if (!(rq->scx.flags & SCX_RQ_CLK_VALID) ||
+ (rq->scx.prev_clock >= clock)) {
As TJ said, it's best to consider that the clock can wrap.
I will improve the presentation using multiple paragraphs
+ /*
+ * If the rq clock is invalid or goes backward,
+ * start a new rq clock period with a fresh sched_clock_cpu().
+ *
+ * The cached rq clock can go backward because there is a
+ * race with a timer interrupt. Suppose that a timer interrupt
+ * occurred while running scx_bpf_now_ns() *after* reading the
+ * rq clock and *before* comparing the if condition. The timer
+ * interrupt will eventually call a BPF scheduler's ops.tick(),
+ * and the BPF scheduler can call scx_bpf_now_ns(). Since the
+ * scheduler core updates the rq clock before calling
+ * ops.tick(), the scx_bpf_now_ns() call will get the fresh
+ * clock. After handling the timer interrupt, the interrupted
+ * scx_bpf_now_ns() will be resumed, so the if condition will
+ * be compared. In this case, the clock, which was read before
+ * the timer interrupt, will be the same as rq->scx.prev_clock.
+ * When such a case is detected, start a new rq clock period
+ * with a fresh sched_clock_cpu().
This has a wall-of-text problem; use paragraphs?
+ clock = sched_clock_cpu(cpu_of(rq));Doesn't this set the VALID bit again? How is using this outside of
+ scx_rq_clock_update(rq, clock);
RQ-lock and setting VALID a good idea?