All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <amc96@srcf.net>
To: "Jan Beulich" <jbeulich@suse.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Cc: James Dingwall <james-xen@dingwall.me.uk>,
	alexander.rossa@ncr.com, xen-devel@lists.xenproject.org
Subject: Re: xen 4.14.3 incorrect (~3x) cpu frequency reported
Date: Mon, 10 Jan 2022 15:43:55 +0000	[thread overview]
Message-ID: <0b2d6240-5780-b8ea-8828-ece44047cd63@srcf.net> (raw)
In-Reply-To: <539e31bc-3e68-9e9d-3bb3-2d0f1b2834fc@suse.com>

On 10/01/2022 13:11, Jan Beulich wrote:
> On 10.01.2022 13:37, Roger Pau Monné wrote:
>> On Fri, Jan 07, 2022 at 12:39:04PM +0100, Jan Beulich wrote:
>>> @@ -415,16 +416,35 @@ static int64_t __init init_hpet(struct p
>>>  
>>>      pts->frequency = hpet_rate;
>>>  
>>> +for(i = 0; i < 16; ++i) {//temp
>>>      count = hpet_read32(HPET_COUNTER);
>>>      start = rdtsc_ordered();
>>>      target = count + CALIBRATE_VALUE(hpet_rate);
>>>      if ( target < count )
>>>          while ( hpet_read32(HPET_COUNTER) >= count )
>>>              continue;
>>> -    while ( hpet_read32(HPET_COUNTER) < target )
>>> +    while ( (count = hpet_read32(HPET_COUNTER)) < target )
>>>          continue;
>>>  
>>> -    return (rdtsc_ordered() - start) * CALIBRATE_FRAC;
>>> +    expired = rdtsc_ordered() - start;
>> There's also a window between the HPET read and the TSC read where an
>> SMI/NMI could cause a wrong frequency detection.
> Right, as said in an earlier reply I did notice this myself (actually
> on the way home on Friday). As also said there, for now I can't see
> any real (i.e. complete) solution to this and the similar instances
> of the issue elsewhere.

Calibration loops like this cannot be made robust.  This is specifically
why frequency information is being made available via architectural
means, and is available via non-architectural means in other cases.

There's a whole bunch of situations (#STOPCLK, TERM and PSMI off the top
of my head, but I bet HDC will screw with things too) which will mess
with any calibration loop, even if you could disable SMIs.  While,
mechanically, we can disable SMIs on AMD with CLGI, we absolutely
shouldn't run a calibration loop like this with SMIs disabled.


Much as I hate to suggest it, we should parse the frequency out of the
long CPUID string, and compare it to the calibration time.  (This
technique is mandated in the Intel BWG during very early setup.)

If it is different by a large margin, rerun the calibration, and if it
is still different, complain loudly into the logs.  This will fix a
one-off-spurious event, whereas if e.g. the system is thermally
throttling due to a bad heat sync, there is nothing software can do to
recover the system.

~Andrew


  reply	other threads:[~2022-01-10 15:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21  9:29 xen 4.11.4 incorrect (~3x) cpu frequency reported James Dingwall
2021-07-21 10:59 ` Jan Beulich
2021-07-26 12:33   ` James Dingwall
2021-11-05 12:50     ` Jan Beulich
2021-11-05 15:25       ` James Dingwall
2022-01-06 15:08         ` xen 4.14.3 " James Dingwall
2022-01-06 16:00           ` Jan Beulich
2022-01-07 11:51             ` Andrew Cooper
2022-01-07 11:39           ` Jan Beulich
2022-01-07 16:37             ` James Dingwall
2022-01-10  7:52             ` Jan Beulich
2022-01-10 14:49               ` Roger Pau Monné
2022-01-10 15:04                 ` Jan Beulich
2022-01-10 12:37             ` Roger Pau Monné
2022-01-10 13:11               ` Jan Beulich
2022-01-10 15:43                 ` Andrew Cooper [this message]
2022-01-10 17:04                   ` Jan Beulich
2022-01-11  5:32                     ` Juergen Gross
2022-01-11  7:09                       ` Jan Beulich
2022-01-11  7:23                     ` Jan Beulich
2022-01-12 16:55               ` Jan Beulich

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=0b2d6240-5780-b8ea-8828-ece44047cd63@srcf.net \
    --to=amc96@srcf.net \
    --cc=alexander.rossa@ncr.com \
    --cc=james-xen@dingwall.me.uk \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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.