Closed Dengerwei closed 1 year ago
@Dengerwei , a new test job has been submitted. Please wait in patience. The test job url: https://tone.openanolis.cn/ws/2r1b4c7z/test_result/43814
@Dengerwei , The CI test is completed, please check result:
Test Case | Test Result | |
---|---|---|
schedule_test | x86_64 | :white_check_mark: SUCCESS |
public_var_test | :white_check_mark: SUCCESS | |
var_uniformity_test | :white_check_mark: SUCCESS | |
cpu_throttle_test | :white_check_mark: SUCCESS | |
domain_rebuild_test | :white_check_mark: SUCCESS | |
sched_syscall_test | :white_check_mark: SUCCESS | |
mem_pressure_test | :white_check_mark: SUCCESS | |
schedule_test | aarch64 | :white_check_mark: SUCCESS |
public_var_test | :white_check_mark: SUCCESS | |
var_uniformity_test | :white_check_mark: SUCCESS | |
cpu_throttle_test | :white_check_mark: SUCCESS | |
domain_rebuild_test | :white_check_mark: SUCCESS | |
sched_syscall_test | :white_check_mark: SUCCESS | |
mem_pressure_test | :white_check_mark: SUCCESS |
Congratulations, your test job passed!
The clock_update_flags is used to skip updating the rq clock. This flag has three values:
%RQCF_REQ_SKIP - will request skipping of clock update on the next call to __schedule().
%RQCF_ACT_SKIP - is set from inside of __schedule() when skipping is in effect and calls to update_rq_clock() are being ignored.
%RQCF_UPDATED - is a debug flag that indicates whether a call has been made to update_rq_clock() since the last time rq::lock was pinned.
So, there have the rules to update the flag. In the update_curr, kernel checks the flag by the assert of assert_clock_updated. If the logic is in skipping context but the flag is RQCF_REQ_SKIP or not set, the warning is triggered.
The idea of scheduler rebuilding comes from sched_setschedule syscall and the sched_cpu_dying, and I find that the update_rq_clock is called before the dequeue/enqueue. Not only the sched_setschedule and the sched_cpu_dying, other logics too. But in our rebuilding, we just call the dequeue/enqueue but miss the update_rq_clock. So I add the update_rq_clock in scheduler rebuilding logic to fix this warning.