linux-kernel - Re: [PATCH] ACPI: Read TSC upon resume

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Oct 2010 14:27:37 -0700
From:	Sameer Nanda <snanda@...omium.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Greg KH <gregkh@...e.de>, lenb@...nel.org,
	stefan.bader@...onical.com, brad.figg@...onical.com,
	apw@...onical.com, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ACPI: Read TSC upon resume

On Thu, Oct 7, 2010 at 12:59 PM, Rafael J. Wysocki <rjw@...k.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@...e.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@...omium.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.

>
> Rafael
>



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