All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Andrew Lutomirski <luto@mit.edu>
Cc: Andi Kleen <andi@firstfloor.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	John Stultz <johnstul@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 0/6] x86-64: Micro-optimize vclock_gettime
Date: Wed, 6 Apr 2011 22:14:42 +0200	[thread overview]
Message-ID: <20110406201442.GV21838@one.firstfloor.org> (raw)
In-Reply-To: <BANLkTi=g96=Q_OOBeejcsZ1eWGZ9cZYLYA@mail.gmail.com>

On Wed, Apr 06, 2011 at 04:10:22PM -0400, Andrew Lutomirski wrote:
> I ran Ingo's time-warp-test w/ 6, 7, and 8 threads on Sandy Bridge and
> on a Xeon 5600 series chip.  My C2D laptop thinks that its TSC halts
> in idle and my only AMD system has unsynchronized TSCs.

I think you should have coverage on more systems. The original
problems that motivated the barriers were on older K8 AMD systems.

You can ask people on l-k to run such tests for you if you don't
have the hardware.

> > I did a similar attempt recently for the in kernel timers.
> > You won't see any difference in a micro benchmark loop, but you may
> > in a workload that dirties lots of cache between timer calls.
> 
> For CLOCK_REALTIME they're already in one cache line.  I tried the
> prefetch and couldn't measure a speedup even after playing with

Did you run a cache pig between the calls? With a tight loop it's obviously
useless.

> Agreed.  In fact, I could do both in one fell swoop: have a flag for
> the mode and have one option be "just issue the syscall."  Static
> branch stuff scares me because this stuff runs in userspace and, in
> theory, userspace might have COWed the page with this code in it.

The vdso is never cowed.

-Andi

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

  reply	other threads:[~2011-04-06 20:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-28 15:06 [PATCH 0/6] x86-64: Micro-optimize vclock_gettime Andy Lutomirski
2011-03-28 15:06 ` [PATCH 1/6] x86-64: Optimize vread_tsc's barriers Andy Lutomirski
2011-03-29  6:18   ` Ingo Molnar
2011-03-28 15:06 ` [PATCH 2/6] x86-64: Don't generate cmov in vread_tsc Andy Lutomirski
2011-03-29  6:15   ` Ingo Molnar
2011-03-29 11:52     ` Andrew Lutomirski
2011-03-28 15:06 ` [PATCH 3/6] x86-64: Put vsyscall_gtod_data at a fixed virtual address Andy Lutomirski
2011-03-28 17:49   ` Thomas Gleixner
2011-03-28 18:09     ` Andrew Lutomirski
2011-03-28 21:35     ` Andrew Lutomirski
2011-03-28 23:13       ` Thomas Gleixner
2011-03-28 15:06 ` [PATCH 4/6] x86-64: vclock_gettime(CLOCK_MONOTONIC) can't ever see nsec < 0 Andy Lutomirski
2011-03-29  6:21   ` Ingo Molnar
2011-03-29 11:54     ` Andrew Lutomirski
2011-03-28 15:06 ` [PATCH 5/6] x86-64: Omit frame pointers on vread_tsc Andy Lutomirski
2011-03-29  6:24   ` Ingo Molnar
2011-03-28 15:06 ` [PATCH 6/6] x86-64: Turn off -pg and turn on -foptimize-sibling-calls for vDSO Andy Lutomirski
2011-03-29  6:27 ` [PATCH 0/6] x86-64: Micro-optimize vclock_gettime Ingo Molnar
2011-04-06 18:20 ` Andi Kleen
2011-04-06 20:10   ` Andrew Lutomirski
2011-04-06 20:14     ` Andi Kleen [this message]
2011-04-06 20:49       ` Andrew Lutomirski

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=20110406201442.GV21838@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=tglx@linutronix.de \
    --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.