On Thursday, October 07, 2010, Sameer Nanda wrote: > On Thu, Oct 7, 2010 at 12:59 PM, Rafael J. Wysocki <rjw@xxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxxxx> > >> >> --- > >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
