Skip to content

Fix sysdev time support

Nigel Cunningham lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest3 patches 5 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/3Fix sysdev time supportarch/i386/kernel/time.c+6 -41 reply
2/3Fix sysdev time supportarch/cris/kernel/time.c arch/i386/kernel/apm.c arch/i386/kernel/i386_ksyms.c +5 more+43 -341 reply
3/3Fix sysdev time supportarch/i386/kernel/time.c+2 -13 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/3] Fix sysdev time support

Hi Andrew et al.

Since Suspend2 (and swsusp) have begun to use the sysdev_suspend and _resume methods, I've discovered some issues with the time support.

time_suspend and _resume call get_cmos_time twice, resulting (!CONFIG_EFI) in an extra second delay for each call (see below). For suspend2, and probably for swsusp (I haven't seen Pavel's handling yet), a call to the _suspend method is almost immediately followed by a call to the _resume method (with the atomic save/restore of memory in between), so that the user sees at least a 3 second delay (ave 1.5 for suspend + 1.5 for resume) simply because of these calls.

get_cmos_time may call efi_get_time, which is marked __init and (according to comments in its header) designed to run in physical mode; I assume, not understanding PAE yet, that this will need further consideration.

get_cmos_time may instead call mach_get_cmos_time (or equiv for other archs), which waits (!x86_64) until the end of a cmos time update before returning the value. For suspending, we don't need to wait for the 'edge' of a second when suspending; we just need a consistent value.

Finally, the calculation of the clock skew due to suspending uses a mixture of signed and unsigned longs. This can result (based on empirical results) in the clock being out by 1 hr, 11 minutes and 31s post resume.

I proposed three patches:
1) Optimise time_suspend and time_resume so that get_cmos_time is called exactly once in each case. This drops 1 second from each call.
2) Add a new parameter & appropriate logic to get_cmos_time and to mach_get_cmos_time and equivalents, allowing the caller to specify whether we should wait for the beginning of a new second. When suspending, don't wait; when resuming, do.
3) Switch sleep_start in arch/i386/kernel/time from a long to an unsigned long, thereby addressing the math issue.

I also wonder if the jiffies+= logic in the x86 code should be applied to x86_64 too?

Regards,

Nigel

Signature · 7 lines
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

You see, at just the right time, when we were still powerless, Christ
died for the ungodly.		-- Romans 5:6