[lkml]   [2004]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] voluntary-preempt-
I wrote :
> Ingo Molnar wrote :
> > here's -P2:
> >
> >
> >
> > Changes since -P1:
> >
> > - trace interrupted kernel code (via hardirqs, NMIs and pagefaults)
> >
> > - yet another shot at trying to fix the IO-APIC/USB issues.
> >
> > - mcount speedups - tracing should be faster
> >
> > Ingo
> Same do_IRQ problem with P2, trace is here :
> Thomas

Ok, maybe that was a false positive. In fact the trace corresponds to
some preempt violation occurring during the boot process :
preemption latency trace v1.0
latency: 136095 us, entries: 4000 (14818)
process: swapper/1, uid: 0
nice: 0, policy: 0, rt_priority: 0
When I reset preempt_max_latency to 100, /proc/latency_trace stays the
same, but the latency time reported is updated to reflect the new
preemtp_max_latency :
root@satellite thomas # diff trace1-P2 trace2-P2
< latency: 136095 us, entries: 4000 (14818)
> latency: 100 us, entries: 4000 (14818)

There still are weird things happening with irq handling, though. how
can generic_redirect_hardirq eat half a millisecond :

preemption latency trace v1.0
latency: 481 us, entries: 32 (32)
process: swapper/0, uid: 0
nice: 0, policy: 0, rt_priority: 0
0.000ms (+0.000ms): do_IRQ (default_idle)
0.000ms (+0.000ms): mask_and_ack_8259A (do_IRQ)
0.459ms (+0.459ms): generic_redirect_hardirq (do_IRQ)
0.459ms (+0.000ms): generic_handle_IRQ_event (do_IRQ)
0.459ms (+0.000ms): timer_interrupt (generic_handle_IRQ_event)
0.459ms (+0.000ms): mark_offset_tsc (timer_interrupt)
0.465ms (+0.005ms): do_timer (timer_interrupt)
0.465ms (+0.000ms): update_process_times (do_timer)
0.465ms (+0.000ms): update_one_process (update_process_times)
0.465ms (+0.000ms): run_local_timers (update_process_times)
0.465ms (+0.000ms): raise_softirq (update_process_times)
0.466ms (+0.000ms): scheduler_tick (update_process_times)
0.466ms (+0.000ms): sched_clock (scheduler_tick)
0.466ms (+0.000ms): update_wall_time (do_timer)
0.466ms (+0.000ms): update_wall_time_one_tick (update_wall_time)
0.466ms (+0.000ms): profile_hook (timer_interrupt)
0.466ms (+0.000ms): notifier_call_chain (profile_hook)
0.467ms (+0.000ms): generic_note_interrupt (do_IRQ)
0.467ms (+0.000ms): end_8259A_irq (do_IRQ)
0.467ms (+0.000ms): enable_8259A_irq (do_IRQ)
0.468ms (+0.000ms): do_softirq (do_IRQ)
0.468ms (+0.000ms): __do_softirq (do_softirq)
0.468ms (+0.000ms): wake_up_process (do_softirq)
0.468ms (+0.000ms): try_to_wake_up (wake_up_process)
0.468ms (+0.000ms): task_rq_lock (try_to_wake_up)
0.468ms (+0.000ms): activate_task (try_to_wake_up)
0.469ms (+0.000ms): sched_clock (activate_task)
0.469ms (+0.000ms): recalc_task_prio (activate_task)
0.469ms (+0.000ms): effective_prio (recalc_task_prio)
0.469ms (+0.000ms): enqueue_task (activate_task)
0.469ms (+0.000ms): preempt_schedule (try_to_wake_up)
0.469ms (+0.000ms): check_preempt_timing (sub_preempt_count)

Is there any source of interruption not covered by your P2 patch ?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.345 / U:12.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site