1. 14 Oct, 2009 1 commit
  2. 12 Oct, 2009 1 commit
  3. 11 Oct, 2009 2 commits
  4. 08 Oct, 2009 1 commit
    • Arjan van de Ven's avatar
      x86, timers: Check for pending timers after (device) interrupts · 9bcbdd9c
      Arjan van de Ven authored
      
      
      Now that range timers and deferred timers are common, I found a
      problem with these using the "perf timechart" tool. Frans Pop also
      reported high scheduler latencies via LatencyTop, when using
      iwlagn.
      
      It turns out that on x86, these two 'opportunistic' timers only get
      checked when another "real" timer happens. These opportunistic
      timers have the objective to save power by hitchhiking on other
      wakeups, as to avoid CPU wakeups by themselves as much as possible.
      
      The change in this patch runs this check not only at timer
      interrupts, but at all (device) interrupts. The effect is that:
      
       1) the deferred timers/range timers get delayed less
      
       2) the range timers cause less wakeups by themselves because
          the percentage of hitchhiking on existing wakeup events goes up.
      
      I've verified the working of the patch using "perf timechart", the
      original exposed bug is gone with this patch. Frans also reported
      success - the latencies are now down in the expected ~10 msec
      range.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Tested-by: default avatarFrans Pop <elendil@planet.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Mike Galbraith <efault@gmx.de>
      LKML-Reference: <20091008064041.67219b13@infradead.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      9bcbdd9c
  5. 03 Oct, 2009 1 commit
  6. 02 Oct, 2009 2 commits
    • Arjan van de Ven's avatar
      x86: Simplify bound checks in the MTRR code · 11879ba5
      Arjan van de Ven authored
      
      
      The current bound checks for copy_from_user in the MTRR driver are
      not as obvious as they could be, and gcc agrees with that.
      
      This patch simplifies the boundary checks to the point that gcc can
      now prove to itself that the copy_from_user() is never going past
      its bounds.
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20090926205150.30797709@infradead.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      11879ba5
    • Ingo Molnar's avatar
      x86: EDAC: MCE: Fix MCE decoding callback logic · f436f8bb
      Ingo Molnar authored
      
      
      Make decoding of MCEs happen only on AMD hardware by registering a
      non-default callback only on CPU families which support it.
      
      While looking at the interaction of decode_mce() with the other MCE
      code i also noticed a few other things and made the following
      cleanups/fixes:
      
       - Fixed the mce_decode() weak alias - a weak alias is really not
         good here, it should be a proper callback. A weak alias will be
         overriden if a piece of code is built into the kernel - not
         good, obviously.
      
       - The patch initializes the callback on AMD family 10h and 11h.
      
       - Added the more correct fallback printk of:
      
      	No support for human readable MCE decoding on this CPU type.
      	Transcribe the message and run it through 'mcelog --ascii' to decode.
      
         On CPUs that dont have a decoder.
      
       - Made the surrounding code more readable.
      
      Note that the callback allows us to have a default fallback -
      without having to check the CPU versions during the printout
      itself. When an EDAC module registers itself, it can install the
      decode-print function.
      
      (there's no unregister needed as this is core code.)
      
      version -v2 by Borislav Petkov:
      
       - add K8 to the set of supported CPUs
      
       - always build in edac_mce_amd since we use an early_initcall now
      
       - fix checkpatch warnings
      Signed-off-by: default avatarBorislav Petkov <borislav.petkov@amd.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      LKML-Reference: <20091001141432.GA11410@aftab>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      f436f8bb
  7. 01 Oct, 2009 2 commits
    • Jason Wessel's avatar
      x86: earlyprintk: Fix regression to handle serial,ttySn as 1 arg · ea3acb19
      Jason Wessel authored
      Commit c9530948
      
       ("early_printk: Allow more than one early console")
      introduced a regression in the parsing of the earlyprintk= kernel
      arguments.
      
      If you specify "earlyprintk=serial,ttyS0,115200" as a kernel
      argument, the "serial,ttyS" should be parsed as a single argument
      and not as "serial" and then "ttyS".
      
      Also update the documentation to reflect you can specify the ttyS
      directly without the "serial" argument.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Greg KH <gregkh@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      LKML-Reference: <4ABB7D5E.6000301@windriver.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      ea3acb19
    • Eric Dumazet's avatar
      x86: Don't generate cmpxchg8b_emu if CONFIG_X86_CMPXCHG64=y · 04edbdef
      Eric Dumazet authored
      
      
      Conditionaly compile cmpxchg8b_emu.o and EXPORT_SYMBOL(cmpxchg8b_emu).
      
      This reduces the kernel size a bit.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <4AC43E7E.1000600@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      04edbdef
  8. 30 Sep, 2009 2 commits
  9. 27 Sep, 2009 1 commit
  10. 24 Sep, 2009 7 commits
  11. 23 Sep, 2009 7 commits
    • Ingo Molnar's avatar
      x86: mce: Use safer ways to access MCE registers · 11868a2d
      Ingo Molnar authored
      Use rdmsrl_safe() when accessing MCE registers. While in
      theory we always 'know' which ones are safe to access from
      the capability bits, there's a lot of hardware variations
      and reality might differ from theory, as it did in this case:
      
         http://bugzilla.kernel.org/show_bug.cgi?id=14204
      
      [    0.010016] mce: CPU supports 5 MCE banks
      [    0.011029] general protection fault: 0000 [#1]
      [    0.011998] last sysfs file:
      [    0.011998] Modules linked in:
      [    0.011998]
      [    0.011998] Pid: 0, comm: swapper Not tainted (2.6.31_router #1
      
      ) HP Vectra
      [    0.011998] EIP: 0060:[<c100d9b9>] EFLAGS: 00010246 CPU: 0
      [    0.011998] EIP is at mce_rdmsrl+0x19/0x60
      [    0.011998] EAX: 00000000 EBX: 00000001 ECX: 00000407 EDX: 08000000
      [    0.011998] ESI: 00000000 EDI: 8c000000 EBP: 00000405 ESP: c17d5eac
      
      So WARN_ONCE() instead of crashing the box.
      
      ( also fix a number of stylistic inconsistencies in the code. )
      
      Note, we might still crash in wrmsrl() if we get that far, but
      we shouldnt if the registers are truly inaccessible.
      Reported-by: default avatarGNUtoo <GNUtoo@no-log.org>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <bug-14204-5438@http.bugzilla.kernel.org/>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      11868a2d
    • Jason Wessel's avatar
      early_printk: Allow more than one early console · c9530948
      Jason Wessel authored
      
      
      It is desirable to be able to use one early boot device to debug
      another or to have multiple places you can see the early boot
      diagnostics, such as the vga screen or serial device.
      
      This patch changes the early_printk console device registration to
      allow more than one early printk device to get registered via
      register_console().
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c9530948
    • Jason Wessel's avatar
      USB: ehci,dbgp,early_printk: split ehci debug driver from early_printk.c · df6c5169
      Jason Wessel authored
      
      
      Move the dbgp early printk driver in advance of refactoring and adding
      new code, so the changes to this code are tracked separately from the
      move of the code.
      
      The drivers/usb/early directory will be the location of the current
      and future early usb code for driving usb devices prior initializing
      the standard interrupt driven USB drivers.
      Signed-off-by: default avatarJason Wessel <jason.wessel@windriver.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      df6c5169
    • Peter Zijlstra's avatar
      perf_event, x86: Fix 'perf sched record' crashing the machine · 7d428966
      Peter Zijlstra authored
      
      
      Chris Malley reported that 'perf sched record' sometimes
      crashes his box with:
      
      [  389.272175] BUG: unable to handle kernel paging request at ffffb300
      [  389.272294] IP: [<c011b0bd>] default_send_IPI_self+0x1d/0x50
      [  389.272366] *pde = 0073f067 *pte = 00000000
      [  389.274708] Call Trace:
      [  389.274752]  [<c010e3b4>] ?  set_perf_event_pending+0x14/0x20
      [  389.274801]  [<c01b9751>] ?  perf_output_unlock+0x121/0x1a0
      [  389.274848]  [<c01b981a>] ? perf_output_end+0x4a/0x70
      [  389.274893]  [<c01ba690>] ?  __perf_event_overflow+0x240/0x2f0
      [  389.274942]  [<c030963e>] ? atomic64_cmpxchg+0x1e/0x30
      [  389.274988]  [<c01ba8f4>] ?  perf_swevent_ctx_event+0x1b4/0x1c0
      [  389.275035]  [<c01ba773>] ?  perf_swevent_ctx_event+0x33/0x1c0
      [  389.275081]  [<c01ba9a7>] ? do_perf_sw_event+0xa7/0x160
      [  389.275127]  [<c01baae2>] ? perf_tp_event+0x82/0xa0
      [  389.275174]  [<c012e9c6>] ?  ftrace_profile_sched_stat_runtime+0xe6/0x120
      [  389.275224]  [<c012e8e0>] ?  ftrace_profile_sched_stat_runtime+0x0/0x120
      [  389.275273]  [<c013c85a>] ? update_curr+0x18a/0x230
      [  389.275318]  [<c013cdc5>] ?  put_prev_task_fair+0x155/0x160
      [  389.275366]  [<c01618b5>] ? sched_clock_cpu+0xd5/0x110
      [  389.275413]  [<c04e7525>] ? _spin_lock_irq+0x45/0x50
      [  389.275458]  [<c04e424e>] ? schedule+0x20e/0xb10
      
      The problem is that the box has no lapic enabled:
      
        [    0.042445] Local APIC not detected. Using dummy APIC emulation.
      
      The below seems like the best fix. We disabled all lapic bits, except
      the self-IPI-resend logic.
      Reported-by: default avatarChris Malley <mail@chrismalley.co.uk>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <7863dc4c0909221409v7893bfd3o4b590d5951a233ba@mail.gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      7d428966
    • Roland McGrath's avatar
      x86: ptrace: set TS_COMPAT when 32-bit ptrace sets orig_eax>=0 · 8cb3ed13
      Roland McGrath authored
      The 32-bit ptrace syscall on a 64-bit kernel (32-bit debugger on
      32-bit task) behaves differently than a native 32-bit kernel.  When
      setting a register state of orig_eax>=0 and eax=-ERESTART* when the
      debugged task is NOT on its way out of a 32-bit syscall, the task will
      fail to do the syscall restart logic that it should do.
      
      Test case available at http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/erestartsys-trap.c?cvsroot=systemtap
      
      
      
      This happens because the 32-bit ptrace syscall sets eax=0xffffffff
      when it sets orig_eax>=0.  The resuming task will not sign-extend this
      for the -ERESTART* check because TS_COMPAT is not set.  (So the task
      thinks it is restarting after a 64-bit syscall, not a 32-bit one.)
      
      The fix is to have 32-bit ptrace calls set TS_COMPAT when setting
      orig_eax>=0.  This ensures that the 32-bit syscall restart logic
      will apply when the child resumes.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      8cb3ed13
    • Roland McGrath's avatar
      x86: ptrace: do not sign-extend orig_ax on write · 08ff18e2
      Roland McGrath authored
      
      
      The high 32 bits of orig_ax will be ignored when it matters,
      so don't fiddle them when setting it.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      08ff18e2
    • Roland McGrath's avatar
      x86: ptrace: sysret path should reach syscall_trace_leave · b60e714d
      Roland McGrath authored
      If TIF_SYSCALL_TRACE or TIF_SINGLESTEP is set while inside a syscall,
      the path back to user mode should get to syscall_trace_leave.
      
      This does happen in most circumstances.  The exception to this is on
      the 64-bit syscall fastpath, when no such flag was set on syscall
      entry and nothing else has punted it off the fastpath for exit.  That
      one exit fastpath fails to check for _TIF_WORK_SYSCALL_EXIT flags.
      This makes the behavior inconsistent with what 32-bit tasks see and
      what the native 32-bit kernel always does, and what 64-bit tasks see
      in all cases where the iret path is taken anyhow.
      
      Perhaps the only example that is affected is a ptrace stop inside
      do_fork (for PTRACE_O_TRACE{CLONE,FORK,VFORK,VFORKDONE}).  Other
      syscalls with internal ptrace stop points (execve) already take the
      iret exit path for unrelated reasons.
      
      Test cases for both PTRACE_SYSCALL and PTRACE_SINGLESTEP variants are at:
      http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/syscall-from-clone.c?cvsroot=systemtap
      http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/step-from-clone.c?cvsroot=systemtap
      
      
      
      There was no special benefit to the sysret path's special path to call
      do_notify_resume, because it always takes the iret exit path at the end.
      So this change just makes the sysret exit path join the iret exit path
      for all the signals and ptrace cases.  The fastpath still applies to
      the plain syscall-audit and resched cases.
      Signed-off-by: default avatarRoland McGrath <roland@redhat.com>
      CC: Oleg Nesterov <oleg@redhat.com>
      b60e714d
  12. 22 Sep, 2009 5 commits
    • Huang Ying's avatar
      x86: mce, inject: Use real inject-msg in raise_local · 14c0abf1
      Huang Ying authored
      
      
      Current raise_local() uses a struct mce that comes from mce_write()
      as a parameter instead of the real inject-msg, so when we set
      mce.finished = 0 to clear injected MCE, the real inject stays
      valid.
      
      This will cause the remaining inject-msg affect the next injection,
      which is not desired.
      
      To fix this, real inject-msg is used in raise_local instead of the
      one on the stack.
      
      This patch is based on the diagnosis and the fixes by Dean Nelson.
      Reported-by: default avatarDean Nelson <dnelson@redhat.com>
      Signed-off-by: default avatarHuang Ying <ying.huang@intel.com>
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <1253601357.15717.757.camel@yhuang-dev.sh.intel.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      14c0abf1
    • Ingo Molnar's avatar
      x86: mce: Fix thermal throttling message storm · b417c9fd
      Ingo Molnar authored
      
      
      If a system switches back and forth between hot and cold mode,
      the MCE code will print a stream of critical kernel messages.
      
      Extend the throttling code to properly notice this, by
      only printing the first hot + cold transition and omitting
      the rest up to CHECK_INTERVAL (5 minutes).
      
      This way we'll only get a single incident of:
      
       [  102.356584] CPU0: Temperature above threshold, cpu clock throttled (total events = 1)
       [  102.357000] Disabling lock debugging due to kernel taint
       [  102.369223] CPU0: Temperature/speed normal
      
      Every 5 minutes. The 'total events' count tells the number of cold/hot
      transitions detected, should overheating occur after 5 minutes again:
      
      [  402.357580] CPU0: Temperature above threshold, cpu clock throttled (total events = 24891)
      [  402.358001] CPU0: Temperature/speed normal
      [  450.704142] Machine check events logged
      
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      b417c9fd
    • Ingo Molnar's avatar
      x86: mce: Clean up thermal throttling state tracking code · 39676840
      Ingo Molnar authored
      
      
      Instead of a mess of three separate percpu variables, consolidate
      the state into a single structure.
      
      Also clean up therm_throt_process(), use cleaner and more
      understandable variable names and a clearer logic.
      
      This, without changing the logic, makes the code more
      streamlined, more readable and smaller as well:
      
         text	   data	    bss	    dec	    hex	filename
         1487	    169	      4	   1660	    67c	therm_throt.o.before
         1432	    176	      4	   1612	    64c	therm_throt.o.after
      
      Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      39676840
    • Jan Beulich's avatar
      mm: don't use alloc_bootmem_low() where not strictly needed · 3c1596ef
      Jan Beulich authored
      
      
      Since alloc_bootmem() will never return inaccessible (via virtual
      addressing) memory anyway, using the ..._low() variant only makes sense
      when the physical address range of the allocated memory must fulfill
      further constraints, espacially since on 64-bits (or more generally in all
      cases where the pools the two variants allocate from are than the full
      available range.
      
      Probably the use in alloc_tce_table() could also be eliminated (based on
      code inspection of pci-calgary_64.c), but that seems too risky given I
      know nothing about that hardware and have no way to test it.
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3c1596ef
    • Jan Beulich's avatar
      mm: replace various uses of num_physpages by totalram_pages · 4481374c
      Jan Beulich authored
      
      
      Sizing of memory allocations shouldn't depend on the number of physical
      pages found in a system, as that generally includes (perhaps a huge amount
      of) non-RAM pages.  The amount of what actually is usable as storage
      should instead be used as a basis here.
      
      Some of the calculations (i.e.  those not intending to use high memory)
      should likely even use (totalram_pages - totalhigh_pages).
      Signed-off-by: default avatarJan Beulich <jbeulich@novell.com>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Dave Airlie <airlied@linux.ie>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4481374c
  13. 21 Sep, 2009 7 commits
    • Michael Tokarev's avatar
      trivial: fix missing printk space in amd_k7_smp_check · 7da8b6dd
      Michael Tokarev authored
      
      
      This trivial patch fixes one missing space in printk.
      
      I already fixed it about half a year ago or more, but the change (in
      arch/x86/kernel/cpu/smpboot.c at that time) didn't made into
      mainline yet.
      Signed-off-by: Michael Tokarev's avatarMichael Tokarev <mjt@tls.msk.ru>
      
      index 28e5f59..6c139ed 100644
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      7da8b6dd
    • Ingo Molnar's avatar
      perf: Tidy up after the big rename · 57c0c15b
      Ingo Molnar authored
      
      
       - provide compatibility Kconfig entry for existing PERF_COUNTERS .config's
      
       - provide courtesy copy of old perf_counter.h, for user-space projects
      
       - small indentation fixups
      
       - fix up MAINTAINERS
      
       - fix small x86 printout fallout
      
       - fix up small PowerPC comment fallout (use 'counter' as in register)
      Reviewed-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      57c0c15b
    • Ingo Molnar's avatar
      perf: Do the big rename: Performance Counters -> Performance Events · cdd6c482
      Ingo Molnar authored
      
      
      Bye-bye Performance Counters, welcome Performance Events!
      
      In the past few months the perfcounters subsystem has grown out its
      initial role of counting hardware events, and has become (and is
      becoming) a much broader generic event enumeration, reporting, logging,
      monitoring, analysis facility.
      
      Naming its core object 'perf_counter' and naming the subsystem
      'perfcounters' has become more and more of a misnomer. With pending
      code like hw-breakpoints support the 'counter' name is less and
      less appropriate.
      
      All in one, we've decided to rename the subsystem to 'performance
      events' and to propagate this rename through all fields, variables
      and API names. (in an ABI compatible fashion)
      
      The word 'event' is also a bit shorter than 'counter' - which makes
      it slightly more convenient to write/handle as well.
      
      Thanks goes to Stephane Eranian who first observed this misnomer and
      suggested a rename.
      
      User-space tooling and ABI compatibility is not affected - this patch
      should be function-invariant. (Also, defconfigs were not touched to
      keep the size down.)
      
      This patch has been generated via the following script:
      
        FILES=$(find * -type f | grep -vE 'oprofile|[^K]config')
      
        sed -i \
          -e 's/PERF_EVENT_/PERF_RECORD_/g' \
          -e 's/PERF_COUNTER/PERF_EVENT/g' \
          -e 's/perf_counter/perf_event/g' \
          -e 's/nb_counters/nb_events/g' \
          -e 's/swcounter/swevent/g' \
          -e 's/tpcounter_event/tp_event/g' \
          $FILES
      
        for N in $(find . -name perf_counter.[ch]); do
          M=$(echo $N | sed 's/perf_counter/perf_event/g')
          mv $N $M
        done
      
        FILES=$(find . -name perf_event.*)
      
        sed -i \
          -e 's/COUNTER_MASK/REG_MASK/g' \
          -e 's/COUNTER/EVENT/g' \
          -e 's/\<event\>/event_id/g' \
          -e 's/counter/event/g' \
          -e 's/Counter/Event/g' \
          $FILES
      
      ... to keep it as correct as possible. This script can also be
      used by anyone who has pending perfcounters patches - it converts
      a Linux kernel tree over to the new naming. We tried to time this
      change to the point in time where the amount of pending patches
      is the smallest: the end of the merge window.
      
      Namespace clashes were fixed up in a preparatory patch - and some
      stylistic fallout will be fixed up in a subsequent patch.
      
      ( NOTE: 'counters' are still the proper terminology when we deal
        with hardware registers - and these sed scripts are a bit
        over-eager in renaming them. I've undone some of that, but
        in case there's something left where 'counter' would be
        better than 'event' we can undo that on an individual basis
        instead of touching an otherwise nicely automated patch. )
      Suggested-by: default avatarStephane Eranian <eranian@google.com>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarPaul Mackerras <paulus@samba.org>
      Reviewed-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <linux-arch@vger.kernel.org>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cdd6c482
    • Ingo Molnar's avatar
      perf_counter: Rename 'event' to event_id/hw_event · dfc65094
      Ingo Molnar authored
      
      
      In preparation to the renames, to avoid a namespace clash.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      dfc65094
    • Tim Abbott's avatar
      Use macros for .data.page_aligned section. · abe1ee3a
      Tim Abbott authored
      
      
      This patch changes the remaining direct references to
      .data.page_aligned in C and assembly code to use the macros in
      include/linux/linkage.h.
      Signed-off-by: default avatarTim Abbott <tabbott@ksplice.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: Sam Ravnborg's avatarSam Ravnborg <sam@ravnborg.org>
      abe1ee3a
    • Tim Abbott's avatar
      Use macros for .bss.page_aligned section. · 02b7da37
      Tim Abbott authored
      
      
      This patch changes the remaining direct references to
      .bss.page_aligned in C and assembly code to use the macros in
      include/linux/linkage.h.
      Signed-off-by: default avatarTim Abbott <tabbott@ksplice.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: Sam Ravnborg's avatarSam Ravnborg <sam@ravnborg.org>
      02b7da37
    • Joe Perches's avatar
  14. 20 Sep, 2009 1 commit
    • Alok Kataria's avatar
      x86: Print the hypervisor returned tsc_khz during boot · 6399c087
      Alok Kataria authored
      
      
      On an AMD-64 system the processor frequency that is printed during
      system boot, may be different than the tsc frequency that was
      returned by the hypervisor, due to the value returned from
      calibrate_cpu.
      
      For debugging timekeeping or other related issues it might be
      better to get the tsc_khz value returned by the hypervisor.
      
      The patch below now prints the tsc frequency that the VMware
      hypervisor returned.
      Signed-off-by: default avatarAlok N Kataria <akataria@vmware.com>
      LKML-Reference: <1252095219.12518.13.camel@ank32.eng.vmware.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      6399c087