1. 24 5月, 2012 7 次提交
  2. 23 5月, 2012 4 次提交
  3. 22 5月, 2012 23 次提交
  4. 19 5月, 2012 2 次提交
    • D
      perf evsel: Create events initially disabled -- again · 5e1c81d9
      David Ahern 提交于
      764e16a3 changed perf-record to create events disabled by default and
      enable them once perf initializations are done. This setting was dropped
      by 0f82ebc4. Now perf events are once again generated during perf's
      initialization phase (e.g., generating maps).
      
      As an example, perf opens a lot of files at startup. Unpatched:
      
      perf record -e syscalls:sys_enter_open -ga -fo /tmp/perf.data -- sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.087 MB /tmp/perf.data (~3798 samples) ]
      
      Using perf-script to look at the samples shows the perf command generating
      563 of the 566 total events.
      
      Patched:
      
      perf record -e syscalls:sys_enter_open -ga -fo /tmp/perf.data -- sleep 1
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.028 MB /tmp/perf.data (~1206 samples) ]
      
      Using perf-script to look at the samples does not show perf command.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Link: http://lkml.kernel.org/r/1336968088-11531-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5e1c81d9
    • S
      ktest: Fix kernelrevision with POST_BUILD · 683a3e64
      Steven Rostedt 提交于
      The PRE_BUILD and POST_BUILD options of ktest are added to allow the
      user to add temporary patch to the system and remove it on builds. This
      is sometimes use to take a change from another git branch and add it to
      a series without the fix so that this series can be tested, when an
      unrelated bug exists in the series.
      
      The problem comes when a tagged commit is being used. For example, if
      v3.2 is being tested, and we add a patch to it, the kernelrelease for
      that commit will be 3.2.0+, but without the patch the version will be
      3.2.0. This can cause problems when the kernelrelease is determined for
      creating the /lib/modules directory. The kernel booting has the '+' but
      the module directory will not, and the modules will be missing for that
      boot, and may not allow the kernel to succeed.
      
      The fix is to put the creation of the kernelrelease in the POST_BUILD
      logic, before it applies the POST_BUILD operation. The POST_BUILD is
      where the patch may be removed, removing the '+' from the kernelrelease.
      
      The calculation of the kernelrelease will also stay in its current
      location but will be ignored if it was already calculated previously.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      683a3e64
  5. 18 5月, 2012 2 次提交
    • J
      perf tools: Split term type into value type and term type · 16fa7e82
      Jiri Olsa 提交于
      Introducing type_val and type_term for term instead of a single type
      value. Currently the term type marked out the value type as well.
      
      With this change we can have future string term values being specified
      by user and translated into proper number along the processing.
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1335371102-11358-2-git-send-email-jolsa@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      16fa7e82
    • J
      perf hists: Fix callchain ip printf format · a0187060
      Jiri Olsa 提交于
      The callchain address is stored as u64. Current code uses following
      format string to display callchain address:
      
        "%p\n", (void *)(long)chain->ip
      
      This way we lose upper 32 bits if we report 64 bit addresses in 32 bit
      environment. Fixing this to always display whole 64 bits.
      
      Note, running following to test perf endianity handling:
      test 1)
        - origin system:
          # perf record -a -- sleep 10 (any perf record will do)
          # perf report > report.origin
          # perf archive perf.data
      
        - copy the perf.data, report.origin and perf.data.tar.bz2
          to a target system and run:
          # tar xjvf perf.data.tar.bz2 -C ~/.debug
          # perf report > report.target
          # diff -u report.origin report.target
      
        - the diff should produce no output
          (besides some white space stuff and possibly different
           date/TZ output)
      
      test 2)
        - origin system:
          # perf record -ag -fo /tmp/perf.data -- sleep 1
        - mount origin system root to the target system on /mnt/origin
        - target system:
          # perf script --symfs /mnt/origin -I -i /mnt/origin/tmp/perf.data \
           --kallsyms /mnt/origin/proc/kallsyms
        - complete perf.data header is displayed
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1337151548-2396-8-git-send-email-jolsa@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a0187060
  6. 17 5月, 2012 2 次提交
    • N
      perf target: Add uses_mmap field · d1cb9fce
      Namhyung Kim 提交于
      If perf doesn't mmap on event (like perf stat), it should not create
      per-task-per-cpu events. So just use a dummy cpu map to create a
      per-task event for this case.
      Signed-off-by: NNamhyung Kim <namhyung.kim@lge.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1337161549-9870-3-git-send-email-namhyung.kim@lge.com
      [ committer note: renamed .need_mmap to .uses_mmap ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d1cb9fce
    • P
      sched: Remove stale power aware scheduling remnants and dysfunctional knobs · 8e7fbcbc
      Peter Zijlstra 提交于
      It's been broken forever (i.e. it's not scheduling in a power
      aware fashion), as reported by Suresh and others sending
      patches, and nobody cares enough to fix it properly ...
      so remove it to make space free for something better.
      
      There's various problems with the code as it stands today, first
      and foremost the user interface which is bound to topology
      levels and has multiple values per level. This results in a
      state explosion which the administrator or distro needs to
      master and almost nobody does.
      
      Furthermore large configuration state spaces aren't good, it
      means the thing doesn't just work right because it's either
      under so many impossibe to meet constraints, or even if
      there's an achievable state workloads have to be aware of
      it precisely and can never meet it for dynamic workloads.
      
      So pushing this kind of decision to user-space was a bad idea
      even with a single knob - it's exponentially worse with knobs
      on every node of the topology.
      
      There is a proposal to replace the user interface with a single
      3 state knob:
      
       sched_balance_policy := { performance, power, auto }
      
      where 'auto' would be the preferred default which looks at things
      like Battery/AC mode and possible cpufreq state or whatever the hw
      exposes to show us power use expectations - but there's been no
      progress on it in the past many months.
      
      Aside from that, the actual implementation of the various knobs
      is known to be broken. There have been sporadic attempts at
      fixing things but these always stop short of reaching a mergable
      state.
      
      Therefore this wholesale removal with the hopes of spurring
      people who care to come forward once again and work on a
      coherent replacement.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1326104915.2442.53.camel@twinsSigned-off-by: NIngo Molnar <mingo@kernel.org>
      8e7fbcbc