All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gong <gong.chen@linux.intel.com>
To: "Koornstra, Reinoud" <koornstra@hp.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Greg KH <gregkh@suse.de>,
	Sameer Nanda <snanda@chromium.org>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"brad.figg@canonical.com" <brad.figg@canonical.com>,
	"apw@canonical.com" <apw@canonical.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ACPI: Read TSC upon resume
Date: Mon, 18 Oct 2010 10:41:48 +0800	[thread overview]
Message-ID: <4CBBB3EC.9000609@linux.intel.com> (raw)
In-Reply-To: <E92FAF79A8BBC642A36EEE3AA7F152D884DB9CA072@GVW1089EXB.americas.hpqcorp.net>

于 10/16/2010 11:03 AM, Koornstra, Reinoud 写道:
>> -----Original Message-----
>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>> owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki
>> Sent: Thursday, October 07, 2010 2:44 PM
>> To: Greg KH
>> Cc: Sameer Nanda; lenb@kernel.org; stefan.bader@canonical.com;
>> brad.figg@canonical.com; apw@canonical.com; linux-acpi@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] ACPI: Read TSC upon resume
>>
>> On Thursday, October 07, 2010, Greg KH wrote:
>>> On Thu, Oct 07, 2010 at 11:05:21AM -0700, Sameer Nanda wrote:
>>>> On Thu, Oct 7, 2010 at 10:46 AM, Greg KH<gregkh@suse.de>  wrote:
>>>>> On Thu, Oct 07, 2010 at 10:43:34AM -0700, Sameer Nanda wrote:
>>>>>> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH<gregkh@suse.de>  wrote:
>>>>>>> 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.
>>>>>
>>>>> Is that really something that users can do something about?
>>>>
>>>> Aside from complaining to the BIOS vendors, no :)
>>>
>>> Then I would not recommend adding this patch, as it is irrelevant for
>>> 99.9999% of all Linux users.
>>
>> It may be somewhat useful, but the rdtscll() call seems to be x86-
>> specific, in
>> which case it shouldn't be used at this place.
>
> Also, in the case of an intel core 2 duo cpu, the tsc is not stable, hence upon resume the cpu is spinning up and the first tsc's will be slower.
> During idle-time the tsc will not be incremented. The tsc is only stably incremented upon 100% cpu usage. It also doesn't increment faster in turbo mode in case of some core 2 duo and certainly the Nehalem cpu's. Calculating in time in terms of tsc might not be so reliable.
>
If I'm wrong, please feel free to fix me.

I have 2 questions to your answer:

1.  CPU has a flag named constant_tsc to keep TSC always working in a 
constant way, so it is irrelvant to the CPU freq. whether in turbo mode 
or any P-state CPU currently belongs to, TSC should be not affected. 
IIRC, this flag should exist long before, at least before Core 2 duo. If 
so, TSC shoule be stable in this kind of environment.

2. though during idle-time TSC will not be incremented, here I want to
remind it is right before Westmere (TSC not always running), and you 
mentioned "upon resume the cpu is spinning up and the first tsc's will 
be slower", I don't know if this commit cd7240c0b can fix it up.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Chen Gong <gong.chen@linux.intel.com>
To: "Koornstra, Reinoud" <koornstra@hp.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Greg KH <gregkh@suse.de>,
	Sameer Nanda <snanda@chromium.org>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"stefan.bader@canonical.com" <stefan.bader@canonical.com>,
	"brad.figg@canonical.com" <brad.figg@canonical.com>,
	"apw@canonical.com" <apw@canonical.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ACPI: Read TSC upon resume
Date: Mon, 18 Oct 2010 10:41:48 +0800	[thread overview]
Message-ID: <4CBBB3EC.9000609@linux.intel.com> (raw)
In-Reply-To: <E92FAF79A8BBC642A36EEE3AA7F152D884DB9CA072@GVW1089EXB.americas.hpqcorp.net>

于 10/16/2010 11:03 AM, Koornstra, Reinoud 写道:
>> -----Original Message-----
>> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
>> owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki
>> Sent: Thursday, October 07, 2010 2:44 PM
>> To: Greg KH
>> Cc: Sameer Nanda; lenb@kernel.org; stefan.bader@canonical.com;
>> brad.figg@canonical.com; apw@canonical.com; linux-acpi@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH] ACPI: Read TSC upon resume
>>
>> On Thursday, October 07, 2010, Greg KH wrote:
>>> On Thu, Oct 07, 2010 at 11:05:21AM -0700, Sameer Nanda wrote:
>>>> On Thu, Oct 7, 2010 at 10:46 AM, Greg KH<gregkh@suse.de>  wrote:
>>>>> On Thu, Oct 07, 2010 at 10:43:34AM -0700, Sameer Nanda wrote:
>>>>>> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH<gregkh@suse.de>  wrote:
>>>>>>> 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.
>>>>>
>>>>> Is that really something that users can do something about?
>>>>
>>>> Aside from complaining to the BIOS vendors, no :)
>>>
>>> Then I would not recommend adding this patch, as it is irrelevant for
>>> 99.9999% of all Linux users.
>>
>> It may be somewhat useful, but the rdtscll() call seems to be x86-
>> specific, in
>> which case it shouldn't be used at this place.
>
> Also, in the case of an intel core 2 duo cpu, the tsc is not stable, hence upon resume the cpu is spinning up and the first tsc's will be slower.
> During idle-time the tsc will not be incremented. The tsc is only stably incremented upon 100% cpu usage. It also doesn't increment faster in turbo mode in case of some core 2 duo and certainly the Nehalem cpu's. Calculating in time in terms of tsc might not be so reliable.
>
If I'm wrong, please feel free to fix me.

I have 2 questions to your answer:

1.  CPU has a flag named constant_tsc to keep TSC always working in a 
constant way, so it is irrelvant to the CPU freq. whether in turbo mode 
or any P-state CPU currently belongs to, TSC should be not affected. 
IIRC, this flag should exist long before, at least before Core 2 duo. If 
so, TSC shoule be stable in this kind of environment.

2. though during idle-time TSC will not be incremented, here I want to
remind it is right before Westmere (TSC not always running), and you 
mentioned "upon resume the cpu is spinning up and the first tsc's will 
be slower", I don't know if this commit cd7240c0b can fix it up.

  reply	other threads:[~2010-10-18  2:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-06 23:15 [PATCH] ACPI: Read TSC upon resume Sameer Nanda
2010-10-07  2:19 ` Greg KH
     [not found]   ` <AANLkTimE2h46iZkj_amvgUg5UwN9xjuwqdW5TB+XccYy@mail.gmail.com>
2010-10-07 17:46     ` Greg KH
2010-10-07 18:05       ` Sameer Nanda
2010-10-07 18:05         ` Sameer Nanda
2010-10-07 18:15         ` Greg KH
2010-10-07 18:15           ` Greg KH
2010-10-07 21:44           ` Rafael J. Wysocki
2010-10-16  3:03             ` Koornstra, Reinoud
2010-10-18  2:41               ` Chen Gong [this message]
2010-10-18  2:41                 ` Chen Gong
2010-10-07 17:58   ` Sameer Nanda
2010-10-07 19:59     ` Rafael J. Wysocki
2010-10-07 21:27       ` Sameer Nanda
2010-10-07 21:27         ` Sameer Nanda
2010-10-07 21:43         ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CBBB3EC.9000609@linux.intel.com \
    --to=gong.chen@linux.intel.com \
    --cc=apw@canonical.com \
    --cc=brad.figg@canonical.com \
    --cc=gregkh@suse.de \
    --cc=koornstra@hp.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=snanda@chromium.org \
    --cc=stefan.bader@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.