[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0809241534400.3265@nehalem.linux-foundation.org>
Date: Wed, 24 Sep 2008 15:41:06 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mathieu Desnoyers <compudj@...stal.dyndns.org>
cc: Martin Bligh <mbligh@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
prasad@...ux.vnet.ibm.com, "Frank Ch. Eigler" <fche@...hat.com>,
David Wilder <dwilder@...ibm.com>, hch@....de,
Tom Zanussi <zanussi@...cast.net>,
Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH 1/3] Unified trace buffer
On Wed, 24 Sep 2008, Linus Torvalds wrote:
>
> - case 1: TSCExtend marker
> data = extended TSC (bits 28..59)
> size = 8
>
> - case 2: TimeStamp marker
> data = tv_nsec
> array[0] = tv_sec
> size = 16
Btw, in case it wasn't clear, those two are totally different things.
The "case 1" thing is the thing that gets inserted automatically by the
trace code when it's needed because the 27-bit TSC is too limited.
The "case 2" thing is to allow us to occasionally synchronize with some
global known wall-time clock like the HPET + xtime. IOW, it would be
something that on demand creates a mapping from wall clock to TSC for that
particular CPU.
I guess I should perhaps have put the TSC frequency in there in that "case
2" thing too. Maybe that should be in "data" (in kHz) and tv_sec/tv_nsec
should be in array[0..1], and the time sync packet would be 24 bytes.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists