public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@linuxmail.org>
To: Andrew Morton <akpm@digeo.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH 0/3] Fix sysdev time support
Date: Fri, 12 Nov 2004 09:58:51 +1100	[thread overview]
Message-ID: <1100213485.6031.18.camel@desktop.cunninghams> (raw)

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
-- 
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


             reply	other threads:[~2004-11-11 23:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-11 22:58 Nigel Cunningham [this message]
2004-11-11 22:58 ` [PATCH 1/3] Fix sysdev time support Nigel Cunningham
2004-11-12  7:58   ` Pavel Machek
2004-11-11 22:59 ` [PATCH 2/3] " Nigel Cunningham
2004-11-12  8:03   ` Pavel Machek
2004-11-11 22:59 ` [PATCH 3/3] " Nigel Cunningham
2004-11-12  8:00   ` Pavel Machek
2004-11-12 20:33     ` Nigel Cunningham
2004-11-12 21:15       ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1100213485.6031.18.camel@desktop.cunninghams \
    --to=ncunningham@linuxmail.org \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox