All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Andy Lutomirski <luto@MIT.EDU>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Nick Piggin <npiggin@suse.de>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFT/PATCH v2 2/6] x86-64: Optimize vread_tsc's barriers
Date: Thu, 7 Apr 2011 17:23:54 +0200	[thread overview]
Message-ID: <20110407152354.GW21838@one.firstfloor.org> (raw)
In-Reply-To: <20110407082550.GG24879@elte.hu>

> Also, do we *really* have RDTSC SMP-coherency guarantees on multi-socket CPUs 
> today? It now works on multi-core, but on bigger NUMA i strongly doubt it. So 
> this hack tries to preserve something that we wont be able to offer anyway.

Some larger NUMA systems have explicit TSC consistency in hardware; on those that don't 
we disable TSC as a clocksource so this path should be never taken.

> So the much better optimization would be to give up on exact GTOD coherency and 
> just make sure the same task does not see time going backwards. If user-space 
> wants precise coherency it can use synchronization primitives itsef. By default 
> it would get the fast and possibly off by a few cycles thing instead. We'd 
> never be seriously jump in time - only small jumps would happen in practice, 
> depending on CPU parallelism effects.

That would be a big user visible break in compatibility.

Any small jump can lead to a negative time difference, and negative time differences
are known to break applications.

e.g. typical case is app using this as a event time stamp into a buffer written
from multiple CPUs, and then assuming that the time stamp always goes up.

> If we do that then the optimization would be to RDTSC and not use *any* of the 
> barriers, neither the hardware ones nor your tricky software data-dependency 
> obfuscation barrier.

The barriers were originally added because a stress test was able to observe
time going backwards without them.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

  parent reply	other threads:[~2011-04-07 15:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-07  2:03 [RFT/PATCH v2 0/6] Micro-optimize vclock_gettime Andy Lutomirski
2011-04-07  2:03 ` [RFT/PATCH v2 1/6] x86-64: Clean up vdso/kernel shared variables Andy Lutomirski
2011-04-07  8:08   ` Ingo Molnar
2011-04-07  2:03 ` [RFT/PATCH v2 2/6] x86-64: Optimize vread_tsc's barriers Andy Lutomirski
2011-04-07  8:25   ` Ingo Molnar
2011-04-07 11:44     ` Andrew Lutomirski
2011-04-07 15:23     ` Andi Kleen [this message]
2011-04-07 17:28       ` Ingo Molnar
2011-04-07 16:18   ` Linus Torvalds
2011-04-07 16:42     ` Andi Kleen
2011-04-07 17:20       ` Linus Torvalds
2011-04-07 18:15         ` Andi Kleen
2011-04-07 18:30           ` Linus Torvalds
2011-04-07 21:26             ` Andrew Lutomirski
2011-04-08 17:59               ` Andrew Lutomirski
2011-04-09 11:51                 ` Ingo Molnar
2011-04-07 21:43         ` Raghavendra D Prabhu
2011-04-07 22:52           ` Andi Kleen
2011-04-07  2:04 ` [RFT/PATCH v2 3/6] x86-64: Don't generate cmov in vread_tsc Andy Lutomirski
2011-04-07  7:54   ` Ingo Molnar
2011-04-07 11:25     ` Andrew Lutomirski
2011-04-07  2:04 ` [RFT/PATCH v2 4/6] x86-64: vclock_gettime(CLOCK_MONOTONIC) can't ever see nsec < 0 Andy Lutomirski
2011-04-07  7:57   ` Ingo Molnar
2011-04-07 11:27     ` Andrew Lutomirski
2011-04-07  2:04 ` [RFT/PATCH v2 5/6] x86-64: Move vread_tsc into a new file with sensible options Andy Lutomirski
2011-04-07  2:04 ` [RFT/PATCH v2 6/6] x86-64: Turn off -pg and turn on -foptimize-sibling-calls for vDSO Andy Lutomirski
2011-04-07  8:03   ` Ingo Molnar

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=20110407152354.GW21838@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@MIT.EDU \
    --cc=mingo@elte.hu \
    --cc=npiggin@suse.de \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.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.