Messages in this thread | | | Date | Wed, 06 Jan 2016 14:06:02 -0500 | From | Prarit Bhargava <> | Subject | Re: [PATCH 1/2] kernel, timekeeping, add trylock option to ktime_get_with_offset() |
| |
On 01/06/2016 02:04 PM, John Stultz wrote: > 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.
I'll convert to this in v2.
Thanks for the input everyone!
P.
> > thanks > -john >
| |