Re: [PATCH] ACPI: Read TSC upon resume

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Thursday, October 07, 2010, Sameer Nanda wrote:
> On Thu, Oct 7, 2010 at 12:59 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Thursday, October 07, 2010, Sameer Nanda wrote:
> >> (resending as plain text, sorry if you got dupe messages)
> >>
> >> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH <gregkh@suse.de> wrote:
> >> > On Wed, Oct 06, 2010 at 04:15:19PM -0700, Sameer Nanda wrote:
> >> >> Read the TSC upon resuming and print it out. This is useful
> >> >> in helping figure out amount of time spent in the BIOS when
> >> >> resuming from suspend.
> >> >>
> >> >> Change-Id: I1d6a32bd62421becddecd152d561763e5f3e1101
> >> >
> >> > What is this tag for?  I don't think it matches anything the kernel
> >> > community wants, do you?
> >>
> >> Yeah, its not needed.  Let me resubmit the patch without this tag.
> >>
> >> >
> >> > And are you always going to be printing this out?  Why do we want to
> >> > know this every time?
> >>
> >> Yes, every time.  This helps track variance in BIOS resume times
> >> within a single boot.
> >>
> >> >
> >> >> Signed-off-by: Sameer Nanda <snanda@chromium.org>
> >> >> ---
> >> >>  drivers/acpi/sleep.c |    4 ++++
> >> >>  1 files changed, 4 insertions(+), 0 deletions(-)
> >> >>
> >> >> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> >> >> index c0fed2e..f0588fa 100644
> >> >> --- a/drivers/acpi/sleep.c
> >> >> +++ b/drivers/acpi/sleep.c
> >> >> @@ -214,6 +214,7 @@ static int acpi_suspend_enter(suspend_state_t pm_state)
> >> >>       acpi_status status = AE_OK;
> >> >>       unsigned long flags = 0;
> >> >>       u32 acpi_state = acpi_target_sleep_state;
> >> >> +     u64 tsc;
> >> >>
> >> >>       ACPI_FLUSH_CPU_CACHE();
> >> >>
> >> >> @@ -235,6 +236,9 @@ static int acpi_suspend_enter(suspend_state_t pm_state)
> >> >>
> >> >>       case ACPI_STATE_S3:
> >> >>               do_suspend_lowlevel();
> >> >> +             rdtscll(tsc);
> >> >> +             printk(KERN_INFO "TSC at resume: %llu\n",
> >> >> +                             (unsigned long long)tsc);
> >> >
> >> > How long does this take, will it slow down resume?
> >>
> >> The impact is ~10us (as measured on an Intel Atom N455 @ 1.66Ghz).
> >> Given that resume time is currently of the order of 1sec, its in the
> >> noise range.
> >
> > Do I think correctly that it assumes the TSC will be updated in the sleep state?
> 
> No, it actually banks on TSC not being updated while the system is in S3 state.
> Theory here being that upon resuming from S3, the CPU gets reset and so TSC
> starts counting up from 0.  Therefore, reading the TSC value in the kernel upon
> resuming gives the number of cycles spent in the BIOS in resume path.

Ah that.  OK, that's more clear now.

Thanks,
Rafael