lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 25 Sep 2008 21:35:23 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Martin Bligh <mbligh@...igh.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"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 Thu, 25 Sep 2008, Jeremy Fitzhardinge wrote:

> Steven Rostedt wrote:
> > How do you get this GTOD read in the ring buffer? If the ring buffer does
> > it without any knowledge from the tracer, it may be doing it a 
> > inappropriate times. This would also imply that the GTOD infrastructure 
> > itself is reentrent safe.  Imagine tracing the GTOD code when the buffer 
> > decides it is about time to add the GTOD timestamp into the buffer. Can 
> > the GTOD handle this recursion. If the GTOD has spinlocks, probably not.
> >   
> 
> It doesn't need to read the GTOD synchronously when writing the trace
> record.  When a tsc event occurs, it needs to store the
> GTOD/tsc/frequency somewhere at that point.  When you next write a trace
> record, if that structure has been updated, you write it into the trace
> before emitting the next delta timestamp.
> 
> In fact you can read the GTOD at almost any time between tsc frequency
> updates, so you can defer it to whenever is convenient.  At the time the
> tsc changes frequency, you emit: (tsc,frequency), and a bit later
> (before it changes again) you emit (tsc,GTOD).  That allows you to
> retroactively compute GTODs for all timestamps.  Obviously it would be
> good to get them as close as possible together.

OK, let me rephrase my question.

How and where do we record this?  Do we keep this information in some 
global variable that we must compare to every time we add a new item in 
the trace?

Do we have the buffer register a call back to record this information?

-- Steve

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ