From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@novell.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"winston.l.wang" <winston.l.wang@intel.com>
Subject: Re: [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits
Date: Thu, 14 Apr 2011 17:48:26 +0100 [thread overview]
Message-ID: <C9CCE3EA.165CF%keir.xen@gmail.com> (raw)
In-Reply-To: <4DA73CBD020000780003BBB0@vpn.id2.novell.com>
On 14/04/2011 17:28, "Jan Beulich" <JBeulich@novell.com> wrote:
>
>> I also simplified the actual writability check itself. I couldn't figure out
>> what the benefit of your more complex approach would be. In fact it looked
>> like it wouldn't work if bit 32 was set already in the TSC counter, as then
>> you would write back an unmodified TSC (and in fact you would detect the
>> wrong way round, as you'd see a big delta if the write silently cleared bit
>> 32 (and bits 33-63)). And the final write of tsc+4*delta, wasn't sure what
>> that was about either! But if you can explain why your test is better I'd be
>> happy to use it as you originally wrote it.
>
> So you were concerned about getting the TSC slightly off, and now
> you flush it to zero, without any attempt to restore the original
> value?
Haha, well it doesn't matter too much if we sync TSCs as we bring them
online anyway. But I agree it makes sense to try if we are only able to
write the lower 32 bits -- we can at least hope the write test happens while
TSC counter is a 32-bit value anyway, and at least we've had a best-effort
attempt to keep TSCs in sync.
> As to my original test being broken - I don't think that was the case:
> The first write used (u32)tsc as the input, so the two writes, if
> happening completely, would be certain to be apart by
> approximately 1<<32 (or more, depending on what was in the
> upper half originally).
Ah yes, I missed the importance of the (u32)tsc write. Fair enough, your way
is better. :-)
> The only case not handled was if the TSC
> overflowed 64 bits during the process - I considered this case
> hypothetical only.
>
> The final write of tsc+4*delta was basically an attempt to restore
> the value that would have been there if we didn't fiddle with it.
But the write is actually tsc + 4*(s32)(tmp-tsc), and tmp has 1U<<32 ORed
into it (because it was read after your second write to the TSC. Perhaps we
should just write back the full original tsc and call that good enough?
-- Keir
> The factor 4 was sort of invented, on the basis that the delta was
> between one write and an immediate read back, with there being
> a total of four such windows (read->write or write->read). As
> one wouldn't get it precise anyway, the number seemed fine to
> me, though just writing back the original values probably wouldn't
> have been much worse.
> Jan
>
next prev parent reply other threads:[~2011-04-14 16:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-14 7:18 [PATCH] x86: don't write_tsc() non-zero values on CPUs updating only the lower 32 bits Jan Beulich
2011-04-14 7:25 ` Keir Fraser
2011-04-14 7:42 ` Jan Beulich
2011-04-14 7:50 ` Keir Fraser
2011-04-14 8:06 ` Jan Beulich
2011-04-14 9:18 ` Keir Fraser
2011-04-14 22:41 ` Dan Magenheimer
2011-04-15 6:40 ` Keir Fraser
2011-04-15 14:34 ` Dan Magenheimer
2011-04-15 17:28 ` Keir Fraser
2011-04-14 7:28 ` Jan Beulich
2011-04-14 16:05 ` Keir Fraser
2011-04-14 16:28 ` Jan Beulich
2011-04-14 16:48 ` Keir Fraser [this message]
2011-04-14 18:33 ` Wang, Winston L
2011-04-14 21:06 ` Keir Fraser
2011-04-14 21:37 ` Wang, Winston L
2011-04-15 7:06 ` Jan Beulich
2011-04-15 7:08 ` Jan Beulich
2011-04-15 7:37 ` Keir Fraser
2011-04-15 14:49 ` Wang, Winston L
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=C9CCE3EA.165CF%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=JBeulich@novell.com \
--cc=winston.l.wang@intel.com \
--cc=xen-devel@lists.xensource.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).