Hello, On 2022/5/27 01:43, Tejun Heo wrote: > Hello, > > On Thu, May 26, 2022 at 09:35:54PM +0800, Chengming Zhou wrote: >> I found many false positive lagging during iocost test. >> >> Since iocg->vtime will be advanced to (vnow - margins.target) >> in hweight_after_donation(), which called throw away excess, >> the iocg->done_vtime will also be advanced that much. >> >> period_at_vtime <--period_vtime--> vnow >> | | >> ---------------------------------------------------> >> |<--->| >> margins.target >> |-> >> vtime, done_vtime > > All it does is shifting the vtime (and done_vtime) within the current window > so that we don't build up budget too lage a budget possibly spanning > multiple periods. Yes, this is necessary. Suppose in the last timer, the iocg doesn't have inflights and have excess, then iocg->vtime = iocg->done_vtime = (period_at_vtime - margins.target) > The lagging detection is supposed to detect IOs which are > issued two+ periods ago which didn't finish in the last period. So, I don't Yes, I understand. > think the above sliding up the window affects that detection given that the > lagging detection is done before the window sliding. All it's checking is > whether there still are in-flight IOs which were issued two+ windows ago, so > how the last window has been fast forwarded shouldn't affect the detection, > no? Right, the lagging detection is done before the window sliding in this period timer. The conditions that it checks vtime, done_vtime have been slided in the last timer. time_after64(vtime, vdone) && time_after64(vtime, now.vnow - MAX_LAGGING_PERIODS * period_vtime) && time_before64(vdone, now.vnow - period_vtime) The first condition says it has some inflights, the second condition is always true if vtime has been slided in the last timer, the third condition will be true if the cost of io completed since last timer < ioc->margins.target. So I think it doesn't check correctly whether it has inflights that were issued two+ windows ago. Thanks. > > Thanks. >
