Messages in this thread | | | Date | Tue, 13 Jul 2004 22:51:24 +1000 | From | Nick Piggin <> | Subject | Re: preempt-timing-2.6.8-rc1 |
| |
William Lee Irwin III wrote: > This patch uses the preemption counter increments and decrements to time > non-preemptible critical sections. > > This is an instrumentation patch intended to help determine the causes of > scheduling latency related to long non-preemptible critical sections. > > Changes from 2.6.7-based patch: > (1) fix unmap_vmas() check correctly this time > (2) add touch_preempt_timing() to cond_resched_lock() > (3) depend on preempt until it's worked out wtf goes wrong without it > > --- timing-2.6.8-rc1.orig/kernel/printk.c 2004-07-11 10:35:31.000000000 -0700 > +++ timing-2.6.8-rc1/kernel/printk.c 2004-07-13 03:56:37.901603496 -0700 > @@ -650,10 +650,8 @@ > */ > void console_conditional_schedule(void) > { > - if (console_may_schedule && need_resched()) { > - set_current_state(TASK_RUNNING); > - schedule(); > - } > + if (console_may_schedule) > + cond_resched(); > }
You should send that one in
> +void dec_preempt_count(void) > +{ > + if (preempt_count() == 1 && system_state == SYSTEM_RUNNING && > + __get_cpu_var(preempt_entry)) { > + u64 hold; > + unsigned long preempt_exit > + = (unsigned long)__builtin_return_address(0); > + hold = sched_clock() - __get_cpu_var(preempt_timings) + 999999; > + do_div(hold, 1000000); > + if (preempt_thresh && hold > preempt_thresh && > + printk_ratelimit()) {
This looks wrong. This means hold times of 1ns to 1000000ns trigger the exceeded 1ms threshold, 1000001 to 2000000 trigger the 2ms one, etc.
Removing the + 999999 gives the correct result: 1000000 - 1999999ns triggers the 1ms threshold 2000000 - 2999999ns triggers the 2ms threshold etc
Or have I missed something? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |