mclock: Fix timer-based scheduling #12
No reviewers
Labels
No labels
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-qos#12
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "dstepanov-yadro/frostfs-qos:fix/mclock_timer_scheduling"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Let's assume that there are two requests in the queue with execution time t1 and t2.
The timer is set to t1. The timer is triggered, schedules the t1 request,
calculates the time for the next timer t2 to be triggered.
But it doesn't schedules timer to this time because of the
q.timeBasedScheduleTs > nextTs
check.480b9aee3d
tof546741c3a
mclock: Fix timer-based schedulingto WIP: mclock: Fix timer-based schedulingHow have you caught this bug?
@ -300,3 +295,1 @@
q.scheduleRequest()
})
q.timeBasedScheduleTs = nextTs
if nextTs == math.MaxFloat64 {
Comparing
float64
with==
rubs me the wrong way, do we have any alternative?fixed
f546741c3a
to1ebed20b9d
1ebed20b9d
to346752477b
@fyrchik wrote in #12 (comment):
Hardware testing
@ -63,0 +59,4 @@
if currentTask != nil {
c.wg.Add(1)
f := currentTask
go func() {
Run f() on separate goroutine to not to stuck on channel push.
WIP: mclock: Fix timer-based schedulingto mclock: Fix timer-based scheduling@ -68,0 +73,4 @@
if s.ts >= currentTs {
// current timer will fire earlier
// so next scheduleRequest will push new schedule event
continue
But what does happen to the scheduled task? It's gone? Will it be rescheduled?
current timer will fire and call
scheduleRequest
, andscheduleRequest
will set timer again ons.ts