On Tue, Feb 09, 2016 at 01:53:04PM +0300, Cyrill Gorcunov wrote: > On Tue, Feb 09, 2016 at 01:29:56PM +0300, Vladimir Davydov wrote: > > > > > > Yes. We take current values then substract the @real_[start_]timespec > > > and return it. IOW they are just monotonic|boottime clocks. > > > > Then I think we should name these files accordingly to avoid confusion. > > ve.clock_{monotonic,boottime} probably. > > It was named so in pcs6, so I tried to preserve naming. But sure I > can rename, that's not a problem.
I mean not ve_struct.start_timespec - its name is perfectly fine - but the cgroup file ve.start_timespec - with your patch it should rather be called ve.clock_monotonic. > > > > > This looks weird to me. Wouldn't it be better if we returned the > > > > timespec as is? > > > > > > No, we have to account real total_sleep_time the container > > > has on the node, because when you close the lid the total > > > sleep time will increse but @real_start_timespec won't > > > as far as I can say and this gonna be wrong. > > > > But you can always calculate the difference in userspace, like > > (CLOCK_BOOTTIME - ve.real_start_timespec), no? > > No I fear not. Look, the calculation of how long container has been > uptime is fully up to the kernel, the @real_[start_]timespec is > not update by the kernel during clock ticks (this is completely > done in timekeeper code). > > Vladimir, maybe I misunderstand you, could you please provide > the pseudocode how you imagine it could work? I mean without > in-kernel time normalization. I suspect I miss something obvious. Before suspending a container, you call clock_gettime for CLOCK_MONOTONIC on the host, then read ve.start_timespec, then save the difference to the image. On restore you read CLOCK_MONOTONIC on the destination host and write (clock - difference) to ve.start_timepsec. This would require more work from userspace though. _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel