Re: [PATCH] ACPI: Read TSC upon resume

[Sameer Nanda]

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.

>
> Rafael
>



-- 
Sameer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/