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, Peter Zijlstra wrote:
>
> Right - if you use raw tsc you're dependent on clock speed, if we'd
> normalize that on ns instead you'd need at least: [...]

Please don't normalize to ns.

It's really quite hard, and it's rather _expensive_ on many CPU's. It
involves a non-constant 64-bit divide, after all. I bet it can be
optimized to be a multiply-by-inverse instead, but it would be a 128-bit
(or maybe just 96-bit?) multiply, and the code would be nasty, and likely
rather more expensive than the TSC reading itself.

Sure, you have to normalize at _some_ point, and normalizing early might
make some things simpler, but the main thing that would become easier is
people messing about in the raw log buffer on their own directly, which
would hopefully be something that we'd discourage _anyway_ (ie we should
try to use helper functions for people to do things like "get the next
event data", not only because the headers are going to be odd due to
trying to pack things together, but because maybe we can more easily
extend on them later that way when nobody accesses the headers by hand).

And I don't think normalizing later is in any way more fundamentally hard.
It just means that you do part of the expensive things after you have
gathered the trace, rather than during.

Linus


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