From: Ingo Molnar <mingo@elte.hu>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
"hpa@zytor.com" <hpa@zytor.com>,
"markus.t.metzger@gmail.com" <markus.t.metzger@gmail.com>,
"roland@redhat.com" <roland@redhat.com>,
"eranian@googlemail.com" <eranian@googlemail.com>,
"oleg@redhat.com" <oleg@redhat.com>,
"Villacis, Juan" <juan.villacis@intel.com>,
"ak@linux.jf.intel.com" <ak@linux.jf.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [patch 01/18] x86, bts: fix race when bts tracer is removed
Date: Fri, 3 Apr 2009 13:30:58 +0200 [thread overview]
Message-ID: <20090403113058.GE31399@elte.hu> (raw)
In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77E9271809B@irsmsx504.ger.corp.intel.com>
* Metzger, Markus T <markus.t.metzger@intel.com> wrote:
> >-----Original Message-----
> >From: Metzger, Markus T
> >Sent: Friday, April 03, 2009 8:20 AM
> >To: Ingo Molnar
>
>
> >>Also, raw use of jiffies_64 is buggy and racy. Why does this use
> >>jiffies to begin with - why not some finer grained time?
> >
> >What would be a good time to use?
>
> I found cpu_clock() declared in sched.h, which is based on TSC and
> seems to be used by the scheduler, as well. Would this be a good
> time to use?
i'd suggest trace_clock() [which maps to cpu_clock() internally], or
trace_clock_global().
See kernel/trace/trace_clock.c about the properties/tradeoffs. Since
this is a user-facing ABI, trace_clock_global() looks more
compelling, despite its global lock.
Ingo
next prev parent reply other threads:[~2009-04-03 11:31 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-02 14:54 [patch 00/18] x86, bts, ptrace, hw-branch-tracer: fixes and cleanups markus.t.metzger
2009-04-02 14:54 ` [patch 01/18] x86, bts: fix race when bts tracer is removed markus.t.metzger
2009-04-02 18:45 ` Ingo Molnar
2009-04-03 6:19 ` Metzger, Markus T
2009-04-03 7:17 ` Metzger, Markus T
2009-04-03 11:30 ` Ingo Molnar [this message]
2009-04-03 11:29 ` Ingo Molnar
2009-04-02 14:54 ` [patch 02/18] sched: add task_is_running() fucntion to sched.h markus.t.metzger
2009-04-02 14:54 ` [patch 03/18] x86, ptrace, bts: defer branch trace stopping markus.t.metzger
2009-04-02 18:40 ` Ingo Molnar
2009-04-02 14:54 ` [patch 04/18] x86, bts: wait until traced task has been scheduled out markus.t.metzger
2009-04-02 19:17 ` Ingo Molnar
2009-04-03 6:22 ` Metzger, Markus T
2009-04-03 11:32 ` Ingo Molnar
2009-04-03 11:36 ` Metzger, Markus T
2009-04-02 14:55 ` [patch 05/18] x86, bts: fix race between per-task and per-cpu branch tracing markus.t.metzger
2009-04-02 14:55 ` [patch 06/18] x86, debugctlmsr: add _on_cpu variants to debugctlmsr functions markus.t.metzger
2009-04-02 14:55 ` [patch 07/18] x86, bts, hw-branch-tracer: add _noirq variants to the debug store interface markus.t.metzger
2009-04-02 14:55 ` [patch 08/18] x86, hw-branch-tracer: allocate selftest iterator on heap markus.t.metzger
2009-04-02 14:55 ` [patch 09/18] x86, ds: fix compiler warning markus.t.metzger
2009-04-02 14:55 ` [patch 10/18] x86, ds: fix bounds check in ds selftest markus.t.metzger
2009-04-02 14:55 ` [patch 11/18] x86, ds: selftest each cpu markus.t.metzger
2009-04-02 14:55 ` [patch 12/18] x86, ds: add task tracing selftest markus.t.metzger
2009-04-02 14:55 ` [patch 13/18] x86, ds: add leakage warning markus.t.metzger
2009-04-02 19:27 ` Ingo Molnar
2009-04-03 6:42 ` Metzger, Markus T
2009-04-02 14:55 ` [patch 14/18] x86, ds: use single debug store cpu configuration markus.t.metzger
2009-04-02 19:29 ` Ingo Molnar
2009-04-03 6:46 ` Metzger, Markus T
2009-04-02 14:55 ` [patch 15/18] x86, ptrace: remove duplicate functionality markus.t.metzger
2009-04-02 14:55 ` [patch 16/18] x86, ds: dont use TIF_DEBUGCTLMSR markus.t.metzger
2009-04-02 14:55 ` [patch 17/18] x86, ds: fix bad ds_reset_pebs() markus.t.metzger
2009-04-02 14:55 ` [patch 18/18] x86, ds: support Core i7 markus.t.metzger
2009-04-02 19:22 ` [patch 00/18] x86, bts, ptrace, hw-branch-tracer: fixes and cleanups 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=20090403113058.GE31399@elte.hu \
--to=mingo@elte.hu \
--cc=ak@linux.jf.intel.com \
--cc=eranian@googlemail.com \
--cc=hpa@zytor.com \
--cc=juan.villacis@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markus.t.metzger@gmail.com \
--cc=markus.t.metzger@intel.com \
--cc=oleg@redhat.com \
--cc=roland@redhat.com \
--cc=tglx@linutronix.de \
/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.