Messages in this thread | | | Date | Tue, 1 Oct 2019 14:04:23 +0200 | From | Petr Mladek <> | Subject | Re: Time stamp value in printk records |
| |
On Mon 2019-09-30 06:33:42, Sodagudi Prasad wrote: > Hi All, > > From Qualcomm side, we would like to check with upstream team about adding > Raw time stamp value to printk records. On Qualcomm soc, there are various > DSPs subsystems are there - for example audio, video and modem DSPs. > Adding raw timer value(along with sched_clock()) in the printk record helps > in the following use cases – > 1) To find out which subsystem crashed first - Whether application > processor crashed first or DSP subsystem? > 2) If there are any system stability issues on the DSP side, what is the > activity on the APPS processor side during that time? > > Initially during the device boot up, printk shed_clock value can be matched > with timer raw value used on the dsp subsystem, but after APPS processor > suspends several times, we don’t have way to correlate the time stamp value > on the DSP and APPS processor. All timers(both apps processor timer and dsp > timers) are derived from globally always on timer on Qualcomm soc, So > keeping global timer raw values in printk records and dsp logs help to > correlate the activity of all the processors in SoC. > > It would be great if upstream team adds common solution this problem if all > soc vendors would get benefit by adding raw timer value to printk records.
There were some proposals in the past. IMHO, the most comprehensive discussion can be found at https://lore.kernel.org/lkml/alpine.DEB.2.20.1711131023170.1851@nanos/
The main requirement is:
+ The main timestamp must have the same semantic on all systems
+ User space parses the timestamp. We must not break the format and semantic.
+ printk() need to get the timestamp a lockless way
Now, different people wanted different clocks in the past. Which brings several problems:
+ configuration + storing + output format so that people/tools know what they read
There is a huge risk that it will get over engineered. Also there is a risk that some userspace tools might parse it and we would need to maintain compatibility forever.
IMHO, the most acceptable idea was to print a line with "all" possible clocks every now and then. It can be done regularly (once a hour/day) or on event (resume).
These are hints and pointers. Feel free to send patches so that we could discuss them.
Best Regards, Petr
| |