1. 05 5月, 2009 5 次提交
    • I
      perf_counter: fix fixed-purpose counter support on v2 Intel-PERFMON · 066d7dea
      Ingo Molnar 提交于
      Fixed-purpose counters stopped working in a simple 'perf stat ls' run:
      
         <not counted>  cache references
         <not counted>  cache misses
      
      Due to:
      
        ef7b3e09: perf_counter, x86: remove vendor check in fixed_mode_idx()
      
      Which made x86_pmu.num_counters_fixed matter: if it's nonzero, the
      fixed-purpose counters are utilized.
      
      But on v2 perfmon this field is not set (despite there being
      fixed-purpose PMCs). So add a quirk to set the number of fixed-purpose
      counters to at least three.
      
      [ Impact: add quirk for three fixed-purpose counters on certain Intel CPUs ]
      
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1241002046-8832-28-git-send-email-robert.richter@amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      066d7dea
    • I
      perf_counter: convert perf_resource_mutex to a spinlock · 1dce8d99
      Ingo Molnar 提交于
      Now percpu counters can be initialized very early. But the init
      sequence uses mutex_lock(). Fortunately, perf_resource_mutex should
      be a spinlock anyway, so convert it.
      
      [ Impact: fix crash due to early init mutex use ]
      
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1dce8d99
    • I
      perf_counter: initialize the per-cpu context earlier · 0d905bca
      Ingo Molnar 提交于
      percpu scheduling for perfcounters wants to take the context lock,
      but that lock first needs to be initialized. Currently it is an
      early_initcall() - but that is too late, the task tick runs much
      sooner than that.
      
      Call it explicitly from the scheduler init sequence instead.
      
      [ Impact: fix access-before-init crash ]
      
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0d905bca
    • P
      perf_counter: x86: fixup nmi_watchdog vs perf_counter boo-boo · ba77813a
      Peter Zijlstra 提交于
      Invert the atomic_inc_not_zero() test so that we will indeed detect the
      first activation.
      
      Also rename the global num_counters, since its easy to confuse with
      x86_pmu.num_counters.
      
      [ Impact: fix non-working perfcounters on AMD CPUs, cleanup ]
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1241455664.7620.4938.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ba77813a
    • I
      perf_counter: round-robin per-CPU counters too · b82914ce
      Ingo Molnar 提交于
      This used to be unstable when we had the rq->lock dependencies,
      but now that they are that of the past we can turn on percpu
      counter RR too.
      
      [ Impact: handle counter over-commit for per-CPU counters too ]
      
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b82914ce
  2. 03 5月, 2009 1 次提交
  3. 02 5月, 2009 4 次提交
  4. 01 5月, 2009 10 次提交
  5. 30 4月, 2009 18 次提交
  6. 29 4月, 2009 2 次提交
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 · 3dacbdad
      Linus Torvalds 提交于
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (24 commits)
        e100: do not go D3 in shutdown unless system is powering off
        netfilter: revised locking for x_tables
        Bluetooth: Fix connection establishment with low security requirement
        Bluetooth: Add different pairing timeout for Legacy Pairing
        Bluetooth: Ensure that HCI sysfs add/del is preempt safe
        net: Avoid extra wakeups of threads blocked in wait_for_packet()
        net: Fix typo in net_device_ops description.
        ipv4: Limit size of route cache hash table
        Add reference to CAPI 2.0 standard
        Documentation/isdn/INTERFACE.CAPI
        update Documentation/isdn/00-INDEX
        ixgbe: Fix WoL functionality for 82599 KX4 devices
        veth: prevent oops caused by netdev destructor
        xfrm: wrong hash value for temporary SA
        forcedeth: tx timeout fix
        net: Fix LL_MAX_HEADER for CONFIG_TR_MODULE
        mlx4_en: Handle page allocation failure during receive
        mlx4_en: Fix cleanup flow on cq activation
        vlan: update vlan carrier state for admin up/down
        netfilter: xt_recent: fix stack overread in compat code
        ...
      3dacbdad
    • P
      perf_counter: powerpc: allow use of limited-function counters · ab7ef2e5
      Paul Mackerras 提交于
      POWER5+ and POWER6 have two hardware counters with limited functionality:
      PMC5 counts instructions completed in run state and PMC6 counts cycles
      in run state.  (Run state is the state when a hardware RUN bit is 1;
      the idle task clears RUN while waiting for work to do and sets it when
      there is work to do.)
      
      These counters can't be written to by the kernel, can't generate
      interrupts, and don't obey the freeze conditions.  That means we can
      only use them for per-task counters (where we know we'll always be in
      run state; we can't put a per-task counter on an idle task), and only
      if we don't want interrupts and we do want to count in all processor
      modes.
      
      Obviously some counters can't go on a limited hardware counter, but there
      are also situations where we can only put a counter on a limited hardware
      counter - if there are already counters on that exclude some processor
      modes and we want to put on a per-task cycle or instruction counter that
      doesn't exclude any processor mode, it could go on if it can use a
      limited hardware counter.
      
      To keep track of these constraints, this adds a flags argument to the
      processor-specific get_alternatives() functions, with three bits defined:
      one to say that we can accept alternative event codes that go on limited
      counters, one to say we only want alternatives on limited counters, and
      one to say that this is a per-task counter and therefore events that are
      gated by run state are equivalent to those that aren't (e.g. a "cycles"
      event is equivalent to a "cycles in run state" event).  These flags
      are computed for each counter and stored in the counter->hw.counter_base
      field (slightly wonky name for what it does, but it was an existing
      unused field).
      
      Since the limited counters don't freeze when we freeze the other counters,
      we need some special handling to avoid getting skew between things counted
      on the limited counters and those counted on normal counters.  To minimize
      this skew, if we are using any limited counters, we read PMC5 and PMC6
      immediately after setting and clearing the freeze bit.  This is done in
      a single asm in the new write_mmcr0() function.
      
      The code here is specific to PMC5 and PMC6 being the limited hardware
      counters.  Being more general (e.g. having a bitmap of limited hardware
      counter numbers) would have meant more complex code to read the limited
      counters when freezing and unfreezing the normal counters, with
      conditional branches, which would have increased the skew.  Since it
      isn't necessary for the code to be more general at this stage, it isn't.
      
      This also extends the back-ends for POWER5+ and POWER6 to be able to
      handle up to 6 counters rather than the 4 they previously handled.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      LKML-Reference: <18936.19035.163066.892208@cargo.ozlabs.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ab7ef2e5