Messages in this thread | | | Date | Wed, 6 Jan 2016 11:04:16 -0800 | Subject | Re: [PATCH 1/2] kernel, timekeeping, add trylock option to ktime_get_with_offset() | From | John Stultz <> |
| |
On Wed, Jan 6, 2016 at 9:34 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Wed, 6 Jan 2016, John Stultz wrote: >> On Wed, Jan 6, 2016 at 5:00 AM, Prarit Bhargava <prarit@redhat.com> wrote: >> > -ktime_t ktime_get_with_offset(enum tk_offsets offs) >> > +ktime_t ktime_get_with_offset(enum tk_offsets offs, int trylock) >> > { >> > struct timekeeper *tk = &tk_core.timekeeper; >> > unsigned int seq; >> > ktime_t base, *offset = offsets[offs]; >> > s64 nsecs; >> > + unsigned long flags = 0; >> > + >> > + if (unlikely(!timekeeping_initialized)) >> > + return ktime_set(0, 0); >> > >> > WARN_ON(timekeeping_suspended); >> > >> > + if (trylock && !raw_spin_trylock_irqsave(&timekeeper_lock, flags)) >> > + return ktime_set(KTIME_MAX, 0); >> >> Wait.. this doesn't make sense. The timekeeper lock is only for reading. >> >> What I was suggesting to you off line is to have something that avoids >> spinning on the seqcounter should if a bug occurs and we IPI all the >> cpus, that we don't deadlock or block any printk messages. > > We could also extend the fast timekeeper with boot/real/tai extensions and use > that for printk. You can use ktime_get_mono_fast_ns() today.
Ack. There'd be a chance for odd values around when the time is set, but for debug printks I think its not critical.
thanks -john
| |