On 2022/5/17 02:46, Tejun Heo wrote: > On Mon, May 16, 2022 at 04:40:45PM +0800, Chengming Zhou wrote: >> When the first iocg activate after blk_iocost_init(), now->vnow >> maybe smaller than ioc->margins.target, cause very large vtarget >> since it's u64. >> >> vtarget = now->vnow - ioc->margins.target; >> atomic64_add(vtarget - vtime, &iocg->vtime); >> >> Then the iocg's vtime will be very large too, larger than now->vnow. > > It's a wrapping counter. Please take a look at how time_before64() and > friends work. Hi Tejun, below is from the trace of test on original code: iocost_iocg_activate: [vda:/user.slice] now=38343468:2171657838 vrate=137438 \ period=0->0 vtime=18446744007162209454 weight=6553600/6553600 hweight=65536/65536 The vtime value is very large, much larger than vnow. Maybe the commit message is a little misleading? And I take a look at how time_before64() work: #define time_after64(a,b) \ (typecheck(__u64, a) && \ typecheck(__u64, b) && \ ((__s64)((b) - (a)) < 0)) #define time_before64(a,b) time_after64(b,a) I still don't get why my changes are wrong. :-) > > Nacked-by: Tejun Heo <tj@xxxxxxxxxx> > > Again, please spend more effort understanding the code before sending these > subtle patches. Ok, will do. This problem is found from the trace of test, then verified fixed using the trace of the same test with this patch. Thanks. > > Thanks. >
