lkml.org 
[lkml]   [2009]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/5] hrtimer: per-cpu cached values of ktime


On Fri, 8 May 2009, Peter Zijlstra wrote:
>
> The regular (hrtimer driven) tick calls ktime_get() 4 times:
>
> hrtimer_interupt()
> ktimer_get()
> __run_hrtimer()
> tick_sched_timer()
> ktimer_get()
> update_process_times()
> run_local_timers()
> rcu_pending()
> printk_tick()
> scheduler_tick()
> sched_clock_tick()
> ktime_get()
> perf_counter_task_tick()
> run_posix_cpu_timers()
> profile_tick()
> hrtimer_forward()
> hrtimer_enqueue()
> tick_program_event()
> tick_dev_program_event()
> ktime_get()
>
> Reduce that to 2 by caching the 1st ktime_get(). By clearing the state on
> irq_exit() this always works, even for !hrtimer ticks.

Ugh. This looks pretty horrid. That special-case cache is just nasty.

Would it be entirely impossible to just instead do ktime_get() once at the
top and just pass it down. Yes, yes, it would involve calling convention
changes, but that sounds way saner than having an ad-hoc cache like this.

With this, you now have magic rules for when you can use the "get from
cache" version, and time goes backwards if you mix them by mistake (ie you
use a non-caching "ktime_get()" in between two caching "ktime_irq_get()"
calls, and now time will have gone backwards from the second to the third
case).

It just seems to be very hacky.

Linus


\
 
 \ /
  Last update: 2009-05-09 21:53    [W:0.178 / U:1.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site