LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Mark Salyzyn <email@example.com> To: Prarit Bhargava <firstname.lastname@example.org>, Petr Mladek <email@example.com>, Thomas Gleixner <firstname.lastname@example.org> Cc: LKML <email@example.com>, Linus Torvalds <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, "H. Peter Anvin" <firstname.lastname@example.org>, Peter Zijlstra <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Sergey Senozhatsky <email@example.com>, Steven Rostedt <firstname.lastname@example.org>, Joe Perches <email@example.com> Subject: Re: [RFC patch 7/7] timekeeping: Hack to use fine grained timestamps during boot Date: Tue, 28 Nov 2017 11:10:02 -0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On 11/28/2017 10:43 AM, Prarit Bhargava wrote: > > On 11/23/2017 07:58 AM, Petr Mladek wrote: >> On Wed 2017-11-15 19:15:38, Thomas Gleixner wrote: >>> For demonstration purposes only. >>> >>> Add a disgusting hack to work around the fact that high resolution clock >>> MONOTONIC accessors are not available during early boot and return stale >>> time stamps accross suspend/resume when the current clocksource is not >>> flagged with CLOCK_SOURCE_SUSPEND_ACCESS_OK. >>> >>> Use local_clock() to provide timestamps in early boot and when the >>> clocksource is not accessible after timekeeping_suspend(). In the >>> suspend/resume case this might cause non monotonic timestamps. >> I get the non-monotonic times even during boot: >> >> [ 0.026709] smp: Bringing up secondary CPUs ... >> [ 0.027973] x86: Booting SMP configuration: >> [ 0.028006] .... node #0, CPUs: #1 >> [ 0.004000] kvm-clock: cpu 1, msr 1:3ff51041, secondary cpu clock >> ^^^^^^^^ >> [ 0.032097] KVM setup async PF for cpu 1 >> [ 0.032766] kvm-stealtime: cpu 1, msr 13b00dc40 >> [ 0.036502] #2 >> [ 0.004000] kvm-clock: cpu 2, msr 1:3ff51081, secondary cpu clock >> ^^^^^^^^ >> [ 0.040062] KVM setup async PF for cpu 2 >> [ 0.040576] kvm-stealtime: cpu 2, msr 13b20dc40 >> [ 0.041304] #3 >> [ 0.004000] kvm-clock: cpu 3, msr 1:3ff510c1, secondary cpu clock >> ^^^^^^^^ >> [ 0.048051] KVM setup async PF for cpu 3 >> [ 0.048554] kvm-stealtime: cpu 3, msr 13b40dc40 >> >> >> To be honest, I do not feel experienced enough to decide which >> solution is acceptable. I would say that only few people care >> about timestamps during boot. On the other hand, some tools > It is extremely important to know what happened and how long it took. I agree > with Petr, we should figure out a way to guarantee that the timestamp is monotonic. > > P. There is no guarantee of sequential order of delivery for kernel prints. [TL;DR] The timestamp may very well be monotonic in the general case, and yet it may take longer to _compose_ or _deliver_ the message (multiprocessor, via vsprint, etc). To get sequential order the timestamp _has_ to be reliably monotonic and _collected_ at incident _before_ anything else, before message is composed, and then (land in-place, post-sorted, what evz?) be presented in time sorted order. User space can also inject into the kernel print buffer, it certainly does not support at-incident timestamp collection as it is delayed already by a syscall or two. We would need to allow user space (via fast vdso) collect timestamp(s), then make it part of the payload of the report to even get close. It is out-of-scope for this RFC to consider rewriting the timestamp acquisition and delivery infrastructure for kernel prints IMHO. For now we all have accepted they will be _somewhat_ sequential within the confines of races and composition. Sincerely -- Mark Salyzyn
next prev parent reply other threads:[~2017-11-28 19:10 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-15 18:15 [RFC patch 0/7] printk: Switch to CLOCK_MONOTONIC and store extra time stamps Thomas Gleixner 2017-11-15 18:15 ` [RFC patch 1/7] timekeeping: Do not unconditionally suspend NMI safe timekeepers Thomas Gleixner 2017-11-15 18:15 ` [RFC patch 2/7] x86/tsc: Set clocksource CLOCK_SOURCE_SUSPEND_ACCESS_OK Thomas Gleixner 2017-11-15 18:15 ` [RFC patch 3/7] printk: Use clock MONOTONIC for timestamps Thomas Gleixner 2017-11-16 7:58 ` Sergey Senozhatsky 2017-11-15 18:15 ` [RFC patch 4/7] timekeeping: Add NMI safe accessor to mono/boot/real clocks Thomas Gleixner 2017-11-17 23:00 ` Steven Rostedt 2017-11-17 23:12 ` Linus Torvalds 2017-11-17 23:43 ` Thomas Gleixner 2017-11-15 18:15 ` [RFC patch 5/7] crash: Add VMCOREINFO_FIELD_AND_OFFSET() Thomas Gleixner 2017-11-23 12:46 ` Petr Mladek 2017-11-15 18:15 ` [RFC patch 6/7] printk: Store mono/boot/real time timestamps Thomas Gleixner 2017-11-23 13:36 ` Petr Mladek 2017-11-15 18:15 ` [RFC patch 7/7] timekeeping: Hack to use fine grained timestamps during boot Thomas Gleixner 2017-11-23 12:58 ` Petr Mladek 2017-11-28 18:43 ` Prarit Bhargava 2017-11-28 18:47 ` Thomas Gleixner 2017-12-08 11:23 ` Petr Mladek 2017-12-08 19:51 ` Thomas Gleixner 2017-11-28 19:10 ` Mark Salyzyn [this message] 2017-11-28 19:45 ` Steven Rostedt 2017-11-28 20:29 ` Mark Salyzyn 2017-11-28 20:38 ` Peter Zijlstra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).