Re: [RFC PATCH 1/3] Unified trace buffer

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> That said, if people think they can do a good job of ns conversion, 
> I'll stop arguing. Quite frankly, I think people are wrong about that, 
> and quite frankly, I think that anybody who looks even for one second 
> at those "alternate" sched_clock() implementations should realize that 
> they aren't suitable, but whatever. I'm not writing the code, I can 
> only try to convince people to not add the insane call-chains we have 
> now.

hm, i'd really hope hw makers see the light and actually make the hw do 
it all. Signs are that they are cozying up to these ideas.

Good and fast timestamps are important, and it is _infinitely_ more easy 
to do it in hw than in sw.

Firstly they need a low-frequency (10khz-100khz) shared clock line 
across all CPUs. A single line - and since it's low frequency it could 
be overlaid on some existing data line and filtered out. That works 
across NUMA nodes as well and physics allows it to be nanosec accurate 
up to dozens of meters or so. Then they need some really cheap way to 
realize what absolute value the clock counts, and read it out every now 
and then in the CPU, and approximate it inbetween, and have a secondary 
stage cheap few-transitors long-latency multiplicator that keeps passing 
on the nanosec-ish value to a register/MSR that can be read out by the 
instruction.

This trivially works fine even if the CPU is turned off. It uses nary 
any power as it's low freq, and can be spread across larger system 
designs too. In fact it would be a totally exciting new capability for 
things like analysis of SMP events. PEBS/BTS could be extended to save 
this kind of timestamp, and suddenly one could see _very_ accurately 
what happens between CPUs, without expensive bus snooping kit.

and CPUs wont go beyond the '~1nsec' event granularity for quite some 
time anyway - so nanoseconds is not a time scale that gets obsoleted 
quickly.

[ i guess this proves it that everyone has his pipe dream ;-) ]

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/