1. 26 2月, 2010 5 次提交
    • P
      perf_events, x86: Split PMU definitions into separate files · f22f54f4
      Peter Zijlstra 提交于
      Split amd,p6,intel into separate files so that we can easily deal with
      CONFIG_CPU_SUP_* things, needed to make things build now that perf_event.c
      relies on symbols from amd.c
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f22f54f4
    • P
      perf_events, x86: Remove superflous MSR writes · 6667661d
      Peter Zijlstra 提交于
      We re-program the event control register every time we reset the count,
      this appears to be superflous, hence remove it.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6667661d
    • P
      perf_events: Simplify code by removing cpu argument to hw_perf_group_sched_in() · 6e37738a
      Peter Zijlstra 提交于
      Since the cpu argument to hw_perf_group_sched_in() is always
      smp_processor_id(), simplify the code a little by removing this argument
      and using the current cpu where needed.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: David Miller <davem@davemloft.net>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <1265890918.5396.3.camel@laptop>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6e37738a
    • S
      perf_events, x86: AMD event scheduling · 38331f62
      Stephane Eranian 提交于
      This patch adds correct AMD NorthBridge event scheduling.
      
      NB events are events measuring L3 cache, Hypertransport traffic. They are
      identified by an event code >= 0xe0. They measure events on the
      Northbride which is shared by all cores on a package. NB events are
      counted on a shared set of counters. When a NB event is programmed in a
      counter, the data actually comes from a shared counter. Thus, access to
      those counters needs to be synchronized.
      
      We implement the synchronization such that no two cores can be measuring
      NB events using the same counters. Thus, we maintain a per-NB allocation
      table. The available slot is propagated using the event_constraint
      structure.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <4b703957.0702d00a.6bf2.7b7d@mx.google.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      38331f62
    • S
      perf_events: Add new start/stop PMU callbacks · d76a0812
      Stephane Eranian 提交于
      In certain situations, the kernel may need to stop and start the same
      event rapidly. The current PMU callbacks do not distinguish between stop
      and release (i.e., stop + free the resource). Thus, a counter may be
      released, then it will be immediately re-acquired. Event scheduling will
      again take place with no guarantee to assign the same counter. On some
      processors, this may event yield to failure to assign the event back due
      to competion between cores.
      
      This patch is adding a new pair of callback to stop and restart a counter
      without actually release the underlying counter resource. On stop, the
      counter is stopped, its values saved and that's it. On start, the value
      is reloaded and counter is restarted (on x86, actual restart is delayed
      until perf_enable()).
      Signed-off-by: NStephane Eranian <eranian@google.com>
      [ added fallback to ->enable/->disable for all other PMUs
        fixed x86_pmu_start() to call x86_pmu.enable()
        merged __x86_pmu_disable into x86_pmu_stop() ]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <4b703875.0a04d00a.7896.ffffb824@mx.google.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d76a0812
  2. 04 2月, 2010 3 次提交
  3. 29 1月, 2010 16 次提交
  4. 28 1月, 2010 1 次提交
    • A
      perf: Fix inconsistency between IP and callchain sampling · 339ce1a4
      Anton Blanchard 提交于
      When running perf across all cpus with backtracing (-a -g), sometimes we
      get samples without associated backtraces:
      
          23.44%         init  [kernel]                     [k] restore
          11.46%         init                       eeba0c  [k] 0x00000000eeba0c
           6.77%      swapper  [kernel]                     [k] .perf_ctx_adjust_freq
           5.73%         init  [kernel]                     [k] .__trace_hcall_entry
           4.69%         perf  libc-2.9.so                  [.] 0x0000000006bb8c
                             |
                             |--11.11%-- 0xfffa941bbbc
      
      It turns out the backtrace code has a check for the idle task and the IP
      sampling does not. This creates problems when profiling an interrupt
      heavy workload (in my case 10Gbit ethernet) since we get no backtraces
      for interrupts received while idle (ie most of the workload).
      
      Right now x86 and sh check that current is not NULL, which should never
      happen so remove that too.
      
      Idle task's exclusion must be performed from the core code, on top
      of perf_event_attr:exclude_idle.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      LKML-Reference: <20100118054707.GT12666@kryten>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      339ce1a4
  5. 21 1月, 2010 1 次提交
  6. 13 1月, 2010 1 次提交
  7. 31 12月, 2009 1 次提交
    • F
      perf: Pass appropriate frame pointer to dump_trace() · 48b5ba9c
      Frederic Weisbecker 提交于
      Pass the frame pointer from the regs of the interrupted path
      to dump_trace() while processing the stack trace.
      
      Currently, dump_trace() takes the current bp and starts the
      callchain from dump_trace() itself. This is wasteful because
      we need to walk through the entire NMI/DEBUG stack before
      retrieving the interrupted point.
      
      We can fix that by just using the frame pointer from the
      captured regs. It points exactly where we want to start.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1262235183-5320-1-git-send-regression-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      48b5ba9c
  8. 28 12月, 2009 1 次提交
  9. 23 12月, 2009 1 次提交
    • A
      arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: avoid cross-CPU interrupts by... · 4a28395d
      Andrew Morton 提交于
      arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: avoid cross-CPU interrupts by using smp_call_function_any()
      
      Presently acpi-cpufreq will perform the MSR read on the first CPU in the
      mask.  That's inefficient if that CPU differs from the current CPU.
      Because we have to perform a cross-CPU call, but we could have run the
      rdmsr on the current CPU.
      
      So switch to using the new smp_call_function_any(), which will perform the
      call on the current CPU if that CPU is present in the mask (it is).
      
      Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
      Cc: Dave Jones <davej@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Zhao Yakui <yakui.zhao@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      4a28395d
  10. 18 12月, 2009 1 次提交
  11. 17 12月, 2009 4 次提交
    • F
      perf events, x86/stacktrace: Fix performance/softlockup by providing a special... · 06d65bda
      Frederic Weisbecker 提交于
      perf events, x86/stacktrace: Fix performance/softlockup by providing a special frame pointer-only stack walker
      
      It's just wasteful for stacktrace users like perf to walk
      through every entries on the stack whereas these only accept
      reliable ones, ie: that the frame pointer validates.
      
      Since perf requires pure reliable stacktraces, it needs a stack
      walker based on frame pointers-only to optimize the stacktrace
      processing.
      
      This might solve some near-lockup scenarios that can be triggered
      by call-graph tracing timer events.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1261024834-5336-2-git-send-regression-fweisbec@gmail.com>
      [ v2: fix for modular builds and small detail tidyup ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      06d65bda
    • F
      perf events, x86/stacktrace: Make stack walking optional · 61c1917f
      Frederic Weisbecker 提交于
      The current print_context_stack helper that does the stack
      walking job is good for usual stacktraces as it walks through
      all the stack and reports even addresses that look unreliable,
      which is nice when we don't have frame pointers for example.
      
      But we have users like perf that only require reliable
      stacktraces, and those may want a more adapted stack walker, so
      lets make this function a callback in stacktrace_ops that users
      can tune for their needs.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1261024834-5336-1-git-send-regression-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      61c1917f
    • R
      cpumask: rename tsk_cpumask to tsk_cpus_allowed · a4636818
      Rusty Russell 提交于
      Noone uses this wrapper yet, and Ingo asked that it be kept consistent
      with current task_struct usage.
      
      (One user crept in via linux-next: fixed)
      
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au.
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tejun Heo <tj@kernel.org>
      a4636818
    • A
      x86, amd: Get multi-node CPU info from NodeId MSR instead of PCI config space · 9d260ebc
      Andreas Herrmann 提交于
      Use NodeId MSR to get NodeId and number of nodes per processor.
      Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      LKML-Reference: <20091216144355.GB28798@alberich.amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      9d260ebc
  12. 16 12月, 2009 1 次提交
    • A
      tree-wide: convert open calls to remove spaces to skip_spaces() lib function · e7d2860b
      André Goddard Rosa 提交于
      Makes use of skip_spaces() defined in lib/string.c for removing leading
      spaces from strings all over the tree.
      
      It decreases lib.a code size by 47 bytes and reuses the function tree-wide:
         text    data     bss     dec     hex filename
        64688     584     592   65864   10148 (TOTALS-BEFORE)
        64641     584     592   65817   10119 (TOTALS-AFTER)
      
      Also, while at it, if we see (*str && isspace(*str)), we can be sure to
      remove the first condition (*str) as the second one (isspace(*str)) also
      evaluates to 0 whenever *str == 0, making it redundant. In other words,
      "a char equals zero is never a space".
      
      Julia Lawall tried the semantic patch (http://coccinelle.lip6.fr) below,
      and found occurrences of this pattern on 3 more files:
          drivers/leds/led-class.c
          drivers/leds/ledtrig-timer.c
          drivers/video/output.c
      
      @@
      expression str;
      @@
      
      ( // ignore skip_spaces cases
      while (*str &&  isspace(*str)) { \(str++;\|++str;\) }
      |
      - *str &&
      isspace(*str)
      )
      Signed-off-by: NAndré Goddard Rosa <andre.goddard@gmail.com>
      Cc: Julia Lawall <julia@diku.dk>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Richard Purdie <rpurdie@rpsys.net>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
      Cc: David Howells <dhowells@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Samuel Ortiz <samuel@sortiz.org>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Takashi Iwai <tiwai@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e7d2860b
  13. 14 12月, 2009 2 次提交
  14. 12 12月, 2009 1 次提交
    • M
      x86: Limit the number of processor bootup messages · 2eaad1fd
      Mike Travis 提交于
      When there are a large number of processors in a system, there
      is an excessive amount of messages sent to the system console.
      It's estimated that with 4096 processors in a system, and the
      console baudrate set to 56K, the startup messages will take
      about 84 minutes to clear the serial port.
      
      This set of patches limits the number of repetitious messages
      which contain no additional information.  Much of this information
      is obtainable from the /proc and /sysfs.   Some of the messages
      are also sent to the kernel log buffer as KERN_DEBUG messages so
      dmesg can be used to examine more closely any details specific to
      a problem.
      
      The new cpu bootup sequence for system_state == SYSTEM_BOOTING:
      
      Booting Node   0, Processors  #1 #2 #3 #4 #5 #6 #7 Ok.
      Booting Node   1, Processors  #8 #9 #10 #11 #12 #13 #14 #15 Ok.
      ...
      Booting Node   3, Processors  #56 #57 #58 #59 #60 #61 #62 #63 Ok.
      Brought up 64 CPUs
      
      After the system is running, a single line boot message is displayed
      when CPU's are hotplugged on:
      
          Booting Node %d Processor %d APIC 0x%x
      
      Status of the following lines:
      
          CPU: Physical Processor ID:		printed once (for boot cpu)
          CPU: Processor Core ID:		printed once (for boot cpu)
          CPU: Hyper-Threading is disabled	printed once (for boot cpu)
          CPU: Thermal monitoring enabled	printed once (for boot cpu)
          CPU %d/0x%x -> Node %d:		removed
          CPU %d is now offline:		only if system_state == RUNNING
          Initializing CPU#%d:		KERN_DEBUG
      Signed-off-by: NMike Travis <travis@sgi.com>
      LKML-Reference: <4B219E28.8080601@sgi.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      2eaad1fd
  15. 11 12月, 2009 1 次提交
    • P
      x86, AMD: Fix stale cpuid4_info shared_map data in shared_cpu_map cpumasks · ebb682f5
      Prarit Bhargava 提交于
      The per_cpu cpuid4_info shared_map can contain stale data when CPUs are added
      and removed.
      
      The stale data can lead to a NULL pointer derefernce panic on a remove of a
      CPU that has had siblings previously removed.
      
      This patch resolves the panic by verifying a cpu is actually online before
      adding it to the shared_cpu_map, only examining cpus that are part of
      the same lower level cache, and by updating other siblings lowest level cache
      maps when a cpu is added.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      LKML-Reference: <20091209183336.17855.98708.sendpatchset@prarit.bos.redhat.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      ebb682f5