1. 20 7月, 2008 26 次提交
  2. 18 7月, 2008 12 次提交
  3. 17 7月, 2008 2 次提交
    • I
      ftrace: do not trace library functions · 2464a609
      Ingo Molnar 提交于
      make function tracing more robust: do not trace library functions.
      
      We've already got a sizable list of exceptions:
      
       ifdef CONFIG_FTRACE
       # Do not profile string.o, since it may be used in early boot or vdso
       CFLAGS_REMOVE_string.o = -pg
       # Also do not profile any debug utilities
       CFLAGS_REMOVE_spinlock_debug.o = -pg
       CFLAGS_REMOVE_list_debug.o = -pg
       CFLAGS_REMOVE_debugobjects.o = -pg
       CFLAGS_REMOVE_find_next_bit.o = -pg
       CFLAGS_REMOVE_cpumask.o = -pg
       CFLAGS_REMOVE_bitmap.o = -pg
       endif
      
      ... and the pattern has been that random library functionality showed
      up in ftrace's critical path (outside of its recursion check), causing
      hard to debug lockups.
      
      So be a bit defensive about it and exclude all lib/*.o functions by
      default. It's not that they are overly interesting for tracing purposes
      anyway. Specific ones can still be traced, in an opt-in manner.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2464a609
    • I
      ftrace: do not trace scheduler functions · c349e0a0
      Ingo Molnar 提交于
      do not trace scheduler functions - it's still a bit fragile
      and can lock up with:
      
        http://redhat.com/~mingo/misc/config-Thu_Jul_17_13_34_52_CEST_2008Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c349e0a0