lkml.org 
[lkml]   [2008]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 1/3] Unified trace buffer


On Thu, 25 Sep 2008, Steven Rostedt wrote:
>
> Slight correction. You can annotate the function with "notrace" and
> that function will not be traced. So the "only be disabled on a per-file
> basis" statement is false.

Ok. It's still true that we absolutely don't want to add random notrace
markers to code just because it's shared with the scheduler. And
"sched_clock()" is not a single function with just a few well-defined
places, nor are all versions of it at all appropriate for tracing (the
non-TSC ones are a total joke - it works for scheduling, but not tracing.
Same goes for the virtualized versions).

> Currently my code calls "ring_buffer_time_stamp" to get the time stamp,
> whatever it will be. Currently it is using sched_clock, but since I have
> it as a wrapper, it shouldn't be too hard to modify later.

Yes. The code looked fine, and had a FIXME. I have no objection to using
it as a known buggy approximation for TSC in order to not force every
architecture to immediately write one when the patch is discussed. But I
literally would expect that on x86, we'd basically just have a function
that does "rdtsc" for the common case, along with possibly a generic
fallback that does "xadd" in the absense of any other reasonable
alternative.

Linus


\
 
 \ /
  Last update: 2008-09-25 19:17    [W:0.250 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site