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
| ||
|
Date: Mon, 26 Feb 2007 15:12:01 -0800 From: Daniel Walker <dwalker@...sta.com> To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> Cc: mbligh@...gle.com, linux-kernel@...r.kernel.org, johnstul@...ibm.com, mingo@...e.hu Subject: Re: [RFC] Fast assurate clock readable from user space and NMI handler On Mon, 2007-02-26 at 17:14 -0500, Mathieu Desnoyers wrote: > For kernel and user space tracing, those small jumps are very annoying : > it can show, in a trace, that a fork() appears on a CPU after the first > schedule() of the thread on the other CPU : scheduling causality relationship > can become very hard to follow. This is only a sample case. Inaccuracy and > periodical modification of the clock time (non monotonic) can cause important > inaccuracy in performance tests, even on UP systems. A monotonic clock, > accessible from anywhere in kernel space (including NMI handler) and > from user space is very useful for performance analysis and, more > generally, for timestamping data in per cpu buffers so it can be later > reordered correctly. What about adding a layer below do_gettimeofday() which just scheds the adjustment process? That might be reasonable .. The NMI, and userspace cases aren't very compelling right now, at least I'm not convinced a whole new timing interface is needed .. The latency tracing system in the -rt branch modifies the gettimeofday facilities , I'm not sure of the correctness of it but it gets called from anyplace in the kernel including NMI's . Here's the function, cycle_t notrace get_monotonic_cycles(void) { cycle_t cycle_now, cycle_delta; /* read clocksource: */ cycle_now = clocksource_read(clock); /* calculate the delta since the last update_wall_time: */ cycle_delta = (cycle_now - clock->cycle_last) & clock->mask; return clock->cycle_last + cycle_delta; } That looks safe. When converting this to nanoseconds you would still get the time adjustments but it would be all at once instead of in little increments .. Daniel - 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