Thank you for looking into this. We are guaranteed that a “future” type is never returned because with our PullPriorityQueue we set allow_limit_break to true. That means that if we otherwise would not be able to schedule an operation because we’d violate the limit, we will still schedule (i.e. return) an operation. You can see that allow_limit_break is set to true when we construct the PullPriorityQueue on line 221 of src/common/mClockPriorityQueue.h [in version 12.2.4]. Were you observing the behavior you describe — an operation being executed multiple times? Please let me know if you have any additional concerns or questions. Eric > On Oct 10, 2018, at 4:54 AM, 韦皓诚 <whc0000001@xxxxxxxxx> wrote: > > Class mClockQueue calls PullPriorityQueue::pull_request in function > "dequeue()" when OSD dequeues a request from opqueue. But > PullPriorityQueue::pull_request may return three types of values > namely "returning", "future", and "none". The type "future" means > that there are some requests in queue, but their tag are greater than > now, so they should be execute in the future but not now. > mClockQueue::dequeue() do not consider about the type of return value > and execute the request immediately. PullPriorityQueue only pops the > request when return "returning" request, so the "future" request would > be remained. This will cause the operation be executed in many times. > > From Weihaocheng
