linux-kernel - Re: [PATCH 3/6] perf record: add time-of-day option

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, 3 Mar 2011 09:51:48 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	David Ahern <daahern@...co.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	linux-perf-users@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>, acme@...stprotocols.net,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Paul Mackerras <paulus@...ba.org>,
	John Stultz <johnstul@...ibm.com>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH 3/6] perf record: add time-of-day option

* David Ahern <daahern@...co.com> wrote:

> > How does all that deal with CLOCK_REALTIME being affected by NTP and
> > settimeofday? Not really, as far as I can tell. It somehow works, but
> > that depends on the frequency of your event injection.
> 
> It is sampled at some periodic rate to get NTP changes. Right now it is
> hardcoded at once an hour. The frequency option can be added to the
> --tod parameter.

As Thomas mentioned, we probably need something more complete than that.

Still your approach is obviously useful and i'd like to stress that explicitly. Have 
you considered another related feature, feeding printk lines as special 'string 
events' into the perf ringbuffer?

It would round up your scheme very nicely: that way you'd have a single, global, 
GTOD-correlated event store/flow for basically every system event you might be 
interested in. You could switch events (and tracepoints) on/off based on need, 
controlling the type and rate of information in a very finegrained way.

If the printk approach works out i'd even suggest that such a facility would need a 
separate tool within perf: 'perf syslog' or 'perf log'. It would heavily reuse 
perf-script and other perf internal facilities, obviously - but you would not be 
tied to any particular sub-tool implementation.

EDAC type events could feed into this as well, giving the tool a broader 'system 
health' aspect as well, beyond the 'system performance analysis' aspect.

Thanks,

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