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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 7 Oct 2010 21:59:31 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Sameer Nanda <snanda@...omium.org>
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 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?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ