1. 20 7月, 2010 5 次提交
  2. 08 7月, 2010 2 次提交
  3. 17 6月, 2010 1 次提交
    • V
      x86: Look for IA32_ENERGY_PERF_BIAS support · 23016bf0
      Venkatesh Pallipadi 提交于
      The new IA32_ENERGY_PERF_BIAS MSR allows system software to give
      hardware a hint whether OS policy favors more power saving,
      or more performance.  This allows the OS to have some influence
      on internal hardware power/performance tradeoffs where the OS
      has previously had no influence.
      
      The support for this feature is indicated by CPUID.06H.ECX.bit3,
      as documented in the Intel Architectures Software Developer's Manual.
      
      This patch discovers support of this feature and displays it
      as "epb" in /proc/cpuinfo.
      Signed-off-by: NVenkatesh Pallipadi <venki@google.com>
      LKML-Reference: <alpine.LFD.2.00.1006032310160.6669@localhost.localdomain>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      23016bf0
  4. 10 6月, 2010 3 次提交
  5. 03 6月, 2010 1 次提交
    • I
      xen: ensure timer tick is resumed even on CPU driving the resume · cd52e17e
      Ian Campbell 提交于
      The core suspend/resume code is run from stop_machine on CPU0 but
      parts of the suspend/resume machinery (including xen_arch_resume) are
      run on whichever CPU happened to schedule the xenwatch kernel thread.
      
      As part of the non-core resume code xen_arch_resume is called in order
      to restart the timer tick on non-boot processors. The boot processor
      itself is taken care of by core timekeeping code.
      
      xen_arch_resume uses smp_call_function which does not call the given
      function on the current processor. This means that we can end up with
      one CPU not receiving timer ticks if the xenwatch thread happened to
      be scheduled on CPU > 0.
      
      Use on_each_cpu instead of smp_call_function to ensure the timer tick
      is resumed everywhere.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Acked-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Stable Kernel <stable@kernel.org> # .32.x
      cd52e17e
  6. 02 6月, 2010 1 次提交
    • B
      x86, smpboot: Fix cores per node printing on boot · 4adc8b71
      Borislav Petkov 提交于
      Percpu initialization happens now after booting the cores on the
      machine and this causes them all to be displayed as belonging to
      node 0:
      
      Jun  8 05:57:21 kepek kernel: [    0.106999] Booting Node   0,
      Processors  #1 #2 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 #13 #14 #15 #16 #17 #18 #19 #20 #21 #22 #23 Ok.
      
      Use early_cpu_to_node() to get the correct node of each core
      instead.
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Mike Travis <travis@sgi.com>
      LKML-Reference: <20100601190455.GA14237@aftab>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4adc8b71
  7. 01 6月, 2010 2 次提交
  8. 31 5月, 2010 3 次提交
    • A
      x86/mm: Remove unused DBG() macro · e565813a
      Akinobu Mita 提交于
      DBG() macro for CONFIG_DEBUG_PER_CPU_MAPS is unused.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      LKML-Reference: <1274706291-13554-1-git-send-email-akinobu.mita@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e565813a
    • S
      perf_events: Fix event scheduling issues introduced by transactional API · 90151c35
      Stephane Eranian 提交于
      The transactional API patch between the generic and model-specific
      code introduced several important bugs with event scheduling, at
      least on X86. If you had pinned events, e.g., watchdog,  and were
      over-committing the PMU, you would get bogus counts. The bug was
      showing up on Intel CPU because events would move around more
      often that on AMD. But the problem also existed on AMD, though
      harder to expose.
      
      The issues were:
      
       - group_sched_in() was missing a cancel_txn() in the error path
      
       - cpuc->n_added was not properly maintained, leading to missing
         actions in hw_perf_enable(), i.e., n_running being 0. You cannot
         update n_added until you know the transaction has succeeded. In
         case of failed transaction n_added was not adjusted back.
      
       - in case of failed transactions, event_sched_out() was called
         and eventually invoked x86_disable_event() to touch the HW reg.
         But with transactions, on X86, event_sched_in() does not touch
         HW registers, it simply collects events into a list. Thus, you
         could end up calling x86_disable_event() on a counter which
         did not correspond to the current event when idx != -1.
      
      The patch modifies the generic and X86 code to avoid all those problems.
      
      First, we keep track of the number of events added last. In case the
      transaction fails, we substract them from n_added. This approach is
      necessary (as opposed to delaying updates to n_added) because not all
      event updates use the transaction API, e.g., single events.
      
      Second, we encapsulate the event_sched_in() and event_sched_out() in
      group_sched_in() inside the transaction. That makes the operations
      symmetrical and you can also detect that you are inside a transaction
      and skip the HW reg access by checking cpuc->group_flag.
      
      With this patch, you can now overcommit the PMU even with pinned
      system-wide events present and still get valid counts.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <1274796225.5882.1389.camel@twins>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      90151c35
    • L
      Revert "cpusets: randomize node rotor used in cpuset_mem_spread_node()" · 35926ff5
      Linus Torvalds 提交于
      This reverts commit 0ac0c0d0, which
      caused cross-architecture build problems for all the wrong reasons.
      IA64 already added its own version of __node_random(), but the fact is,
      there is nothing architectural about the function, and the original
      commit was just badly done. Revert it, since no fix is forthcoming.
      Requested-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      35926ff5
  9. 28 5月, 2010 11 次提交
  10. 27 5月, 2010 2 次提交
  11. 26 5月, 2010 3 次提交
    • L
      Revert "endian: #define __BYTE_ORDER" · 13da9e20
      Linus Torvalds 提交于
      This reverts commit b3b77c8c, which was
      also totally broken (see commit 0d2daf5c that reverted the crc32
      version of it).  As reported by Stephen Rothwell, it causes problems on
      big-endian machines:
      
      > In file included from fs/jfs/jfs_types.h:33,
      >                  from fs/jfs/jfs_incore.h:26,
      >                  from fs/jfs/file.c:22:
      > fs/jfs/endian24.h:36:101: warning: "__LITTLE_ENDIAN" is not defined
      
      The kernel has never had that crazy "__BYTE_ORDER == __LITTLE_ENDIAN"
      model.  It's not how we do things, and it isn't how we _should_ do
      things.  So don't go there.
      Requested-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      13da9e20
    • B
      x86, k8: Fix section mismatch for powernowk8_exit() · fe501f1e
      Borislav Petkov 提交于
      Fix the following warning:
      
      "WARNING: arch/x86/kernel/built-in.o(.exit.text+0x72):
      Section mismatch in reference from the function powernowk8_exit() to the variable .cpuinit.data:cpb_nb
      
      The function __exit powernowk8_exit() references a variable
      __cpuinitdata cpb_nb. This is often seen when error handling in the exit
      function uses functionality in the init path. The fix is often to remove
      the __cpuinitdata annotation of cpb_nb so it may be used outside an init
      section."
      
      Cc: <stable@kernel.org>
      Reported-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <20100525152858.GA24836@aftab>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      fe501f1e
    • K
      driver core: add devname module aliases to allow module on-demand auto-loading · 578454ff
      Kay Sievers 提交于
      This adds:
        alias: devname:<name>
      to some common kernel modules, which will allow the on-demand loading
      of the kernel module when the device node is accessed.
      
      Ideally all these modules would be compiled-in, but distros seems too
      much in love with their modularization that we need to cover the common
      cases with this new facility. It will allow us to remove a bunch of pretty
      useless init scripts and modprobes from init scripts.
      
      The static device node aliases will be carried in the module itself. The
      program depmod will extract this information to a file in the module directory:
        $ cat /lib/modules/2.6.34-00650-g537b60d1-dirty/modules.devname
        # Device nodes to trigger on-demand module loading.
        microcode cpu/microcode c10:184
        fuse fuse c10:229
        ppp_generic ppp c108:0
        tun net/tun c10:200
        dm_mod mapper/control c10:235
      
      Udev will pick up the depmod created file on startup and create all the
      static device nodes which the kernel modules specify, so that these modules
      get automatically loaded when the device node is accessed:
        $ /sbin/udevd --debug
        ...
        static_dev_create_from_modules: mknod '/dev/cpu/microcode' c10:184
        static_dev_create_from_modules: mknod '/dev/fuse' c10:229
        static_dev_create_from_modules: mknod '/dev/ppp' c108:0
        static_dev_create_from_modules: mknod '/dev/net/tun' c10:200
        static_dev_create_from_modules: mknod '/dev/mapper/control' c10:235
        udev_rules_apply_static_dev_perms: chmod '/dev/net/tun' 0666
        udev_rules_apply_static_dev_perms: chmod '/dev/fuse' 0666
      
      A few device nodes are switched to statically allocated numbers, to allow
      the static nodes to work. This might also useful for systems which still run
      a plain static /dev, which is completely unsafe to use with any dynamic minor
      numbers.
      
      Note:
      The devname aliases must be limited to the *common* and *single*instance*
      device nodes, like the misc devices, and never be used for conceptually limited
      systems like the loop devices, which should rather get fixed properly and get a
      control node for losetup to talk to, instead of creating a random number of
      device nodes in advance, regardless if they are ever used.
      
      This facility is to hide the mess distros are creating with too modualized
      kernels, and just to hide that these modules are not compiled-in, and not to
      paper-over broken concepts. Thanks! :)
      
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Chris Mason <chris.mason@oracle.com>
      Cc: Alasdair G Kergon <agk@redhat.com>
      Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
      Cc: Ian Kent <raven@themaw.net>
      Signed-Off-By: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      578454ff
  12. 25 5月, 2010 6 次提交