Sukadev Bhattiprolu wrote: > Oren Laadan [orenl@xxxxxxxxxxxxxxx] wrote: > | > | > | > h->fl_type = lock->fl_type; > | > + h->fl_type_prev = lock->fl_type_prev; > | > h->fl_flags = lock->fl_flags; > | > + if (h->fl_type & F_INPROGRESS && > | > + (lock->fl_break_time > jiffies)) > | > + h->fl_rem_lease = (lock->fl_break_time - jiffies) / HZ; > | > | Hmmm -- we have a ctx->ktime_begin marking the start of the checkpoint. > | It is used for relative-time calculations, for example, the expiry of > | restart-blocks and timeouts. I suggest that we use it here too to be > | consistent. > > Well, I started off using ktime_begin but discussed this with John Stultz > (CC'd here) who pointed out that mixing different domains of time is likely > to cause errors. ktime is an absolute time and fl_break_time uses jiffies - > a relative time. > > I think use of ktime_begin for restart_blocks is fine (since they use > ktime_t) but using ktime_t for file leases and converting between jiffies > and nanoseconds could be a problem, unless we convert fl_break_time to > seconds. > > IOW, can we leave the above computation of ->fl_rem_lease for now ? The data on restart_blocks keep relative time - it's the the time to expiry relative to ktime_begin (which is absolute). ktime_begin merely gives a reference point in time against which all other time-related values should be saved. The advantage is that all time computation are relative to the same point in time at checkpoint/restart - the time when the ktime_begin is set. It's more consistent this way. I don't see the problem with jiffies vs ktime - there are functions to convert between different units (see jiffies.h). Even if you are concerned about reducing the resolution because of a conversion - well, it isn't realistic to expect nano-sec resolution after restart... Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
