1. 18 8月, 2014 2 次提交
    • J
      x86: Support compiling out human-friendly processor feature names · 9def39be
      Josh Triplett 提交于
      The table mapping CPUID bits to human-readable strings takes up a
      non-trivial amount of space, and only exists to support /proc/cpuinfo
      and a couple of kernel messages.  Since programs depend on the format of
      /proc/cpuinfo, force inclusion of the table when building with /proc
      support; otherwise, support omitting that table to save space, in which
      case the kernel messages will print features numerically instead.
      
      In addition to saving 1408 bytes out of vmlinux, this also saves 1373
      bytes out of the uncompressed setup code, which contributes directly to
      the size of bzImage.
      Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
      9def39be
    • J
      x86: Drop support for /proc files when !CONFIG_PROC_FS · 39f838e0
      Josh Triplett 提交于
      arch/x86/kernel/cpu/proc.c only exists to support files in /proc; omit that
      file when compiling without CONFIG_PROC_FS.
      
      Saves 645 additional bytes on 32-bit x86 when !CONFIG_PROC_FS:
      
      add/remove: 0/5 grow/shrink: 0/0 up/down: 0/-645 (-645)
      function                                     old     new   delta
      c_stop                                         1       -      -1
      c_next                                        11       -     -11
      cpuinfo_op                                    16       -     -16
      c_start                                       24       -     -24
      show_cpuinfo                                 593       -    -593
      Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
      39f838e0
  2. 14 1月, 2014 1 次提交
  3. 27 11月, 2013 1 次提交
    • S
      perf/x86: Add Intel RAPL PMU support · 4788e5b4
      Stephane Eranian 提交于
      This patch adds a new uncore PMU to expose the Intel
      RAPL energy consumption counters. Up to 3 counters,
      each counting a particular RAPL event are exposed.
      
      The RAPL counters are available on Intel SandyBridge,
      IvyBridge, Haswell. The server skus add a 3rd counter.
      
      The following events are available and exposed in sysfs:
      
        - power/energy-cores: power consumption of all cores on socket
        - power/energy-pkg: power consumption of all cores + LLc cache
        - power/energy-dram: power consumption of DRAM (servers only)
      
      For each event both the unit (Joules) and scale (2^-32 J)
      is exposed in sysfs for use by perf stat and other tools.
      The files are:
      
      	/sys/devices/power/events/energy-*.unit
      	/sys/devices/power/events/energy-*.scale
      
      The RAPL PMU is uncore by nature and is implemented such
      that it only works in system-wide mode. Measuring only
      one CPU per socket is sufficient. The /sys/devices/power/cpumask
      file can be used by tools to figure out which CPUs to monitor
      by default. For instance, on a 2-socket system, 2 CPUs
      (one on each socket) will be shown.
      
      All the counters measure in the same unit (exposed via sysfs).
      The perf_events API exposes all RAPL counters as 64-bit integers
      counting in unit of 1/2^32 Joules (about 0.23 nJ). User level tools
      must convert the counts by multiplying them by 2^-32 to obtain
      Joules. The reason for this is that the kernel avoids
      doing floating point math whenever possible because it is
      expensive (user floating-point state must be saved). The method
      used avoids kernel floating-point usage. There is no loss of
      precision. Thanks to PeterZ for suggesting this approach.
      
      To convert the raw count in Watt:
         W = C * 2.3 / (1e10 * time)
      or ldexp(C, -32).
      
      RAPL PMU is a new standalone PMU which registers with the
      perf_event core subsystem. The PMU type (attr->type) is
      dynamically allocated and is available from /sys/device/power/type.
      
      Sampling is not supported by the RAPL PMU. There is no
      privilege level filtering either.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Reviewed-by: NMaria Dimakopoulou <maria.n.dimakopoulou@gmail.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: acme@redhat.com
      Cc: jolsa@redhat.com
      Cc: zheng.z.yan@intel.com
      Cc: bp@alien8.de
      Link: http://lkml.kernel.org/r/1384275531-10892-4-git-send-email-eranian@google.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      4788e5b4
  4. 19 6月, 2013 1 次提交
  5. 30 4月, 2013 1 次提交
  6. 21 4月, 2013 1 次提交
  7. 05 3月, 2013 1 次提交
  8. 04 10月, 2012 1 次提交
  9. 24 7月, 2012 1 次提交
  10. 18 6月, 2012 1 次提交
  11. 27 1月, 2012 1 次提交
    • A
      Add driver auto probing for x86 features v4 · 644e9cbb
      Andi Kleen 提交于
      There's a growing number of drivers that support a specific x86 feature
      or CPU.  Currently loading these drivers currently on a generic
      distribution requires various driver specific hacks and it often
      doesn't work.
      
      This patch adds auto probing for drivers based on the x86 cpuid
      information, in particular based on vendor/family/model number
      and also based on CPUID feature bits.
      
      For example a common issue is not loading the SSE 4.2 accelerated
      CRC module: this can significantly lower the performance of BTRFS
      which relies on fast CRC.
      
      Another issue is loading the right CPUFREQ driver for the current CPU.
      Currently distributions often try all all possible driver until
      one sticks, which is not really a good way to do this.
      
      It works with existing udev without any changes. The code
      exports the x86 information as a generic string in sysfs
      that can be matched by udev's pattern matching.
      
      This scheme does not support numeric ranges, so if you want to
      handle e.g. ranges of model numbers they have to be encoded
      in ASCII or simply all models or families listed. Fixing
      that would require changing udev.
      
      Another issue is that udev will happily load all drivers that match,
      there is currently no nice way to stop a specific driver from
      being loaded if it's not needed (e.g. if you don't need fast CRC)
      But there are not that many cpu specific drivers around and they're
      all not that bloated, so this isn't a particularly serious issue.
      
      Originally this patch added the modalias to the normal cpu
      sysdevs. However sysdevs don't have all the infrastructure
      needed for udev, so it couldn't really autoload drivers.
      This patch instead adds the CPU modaliases to the cpuid devices,
      which are real devices with full support for udev. This implies
      that the cpuid driver has to be loaded to use this.
      
      This patch just adds infrastructure, some driver conversions
      in followups.
      
      Thanks to Kay for helping with some sysfs magic.
      
      v2: Constifcation, some updates
      v4: (trenn@suse.de):
          - Use kzalloc instead of kmalloc to terminate modalias buffer
          - Use uppercase hex values to match correctly against hex values containing
            letters
      
      Cc: Dave Jones <davej@redhat.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Jen Axboe <axboe@kernel.dk>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      644e9cbb
  12. 10 10月, 2011 1 次提交
  13. 26 9月, 2011 1 次提交
  14. 01 8月, 2011 1 次提交
    • H
      x86, random: Verify RDRAND functionality and allow it to be disabled · 49d859d7
      H. Peter Anvin 提交于
      If the CPU declares that RDRAND is available, go through a guranteed
      reseed sequence, and make sure that it is actually working (producing
      data.)   If it does not, disable the CPU feature flag.
      
      Allow RDRAND to be disabled on the command line (as opposed to at
      compile time) for a user who has special requirements with regards to
      random numbers.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      49d859d7
  15. 20 5月, 2011 1 次提交
  16. 29 7月, 2010 1 次提交
  17. 20 7月, 2010 1 次提交
    • H
      x86, cpu: Split addon_cpuid_features.c · 2decb194
      H. Peter Anvin 提交于
      addon_cpuid_features.c contains exactly two almost completely
      unrelated functions, plus has a long and very generic name.  Split it
      into two files, scattered.c for the scattered feature flags, and
      topology.c for the topology information.
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      LKML-Reference: <tip-*@git.kernel.org>
      2decb194
  18. 07 5月, 2010 1 次提交
    • K
      x86: Detect running on a Microsoft HyperV system · a2a47c6c
      Ky Srinivasan 提交于
      This patch integrates HyperV detection within the framework currently
      used by VmWare. With this patch, we can avoid having to replicate the
      HyperV detection code in each of the Microsoft HyperV drivers.
      
      Reworked and tweaked by Greg K-H to build properly.
      Signed-off-by: NK. Y. Srinivasan <ksrinivasan@novell.com>
      LKML-Reference: <20100506190841.GA1605@kroah.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Vadim Rozenfeld <vrozenfe@redhat.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Gleb Natapov <gleb@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: "K.Prasad" <prasad@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Alan Cox <alan@linux.intel.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Hank Janssen <hjanssen@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      a2a47c6c
  19. 24 1月, 2010 1 次提交
    • H
      x86: Remove "x86 CPU features in debugfs" (CONFIG_X86_CPU_DEBUG) · b1600918
      H. Peter Anvin 提交于
      CONFIG_X86_CPU_DEBUG, which provides some parsed versions of the x86
      CPU configuration via debugfs, has caused boot failures on real
      hardware.  The value of this feature has been marginal at best, as all
      this information is already available to userspace via generic
      interfaces.
      
      Causes crashes that have not been fixed + minimal utility -> remove.
      
      See the referenced LKML thread for more information.
      Reported-by: NOzan Çağlayan <ozan@pardus.org.tr>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      LKML-Reference: <alpine.LFD.2.00.1001221755320.13231@localhost.localdomain>
      Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: <stable@kernel.org>
      b1600918
  20. 23 11月, 2009 1 次提交
  21. 21 9月, 2009 1 次提交
    • I
      perf: Do the big rename: Performance Counters -> Performance Events · cdd6c482
      Ingo Molnar 提交于
      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: NStephane Eranian <eranian@google.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Reviewed-by: NArjan 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: NIngo Molnar <mingo@elte.hu>
      cdd6c482
  22. 15 9月, 2009 1 次提交
    • P
      x86: sched: Provide arch implementations using aperf/mperf · 47fe38fc
      Peter Zijlstra 提交于
      APERF/MPERF support for cpu_power.
      
      APERF/MPERF is arch defined to be a relative scale of work capacity
      per logical cpu, this is assumed to include SMT and Turbo mode.
      
      APERF/MPERF are specified to both reset to 0 when either counter
      wraps, which is highly inconvenient, since that'll give a blimp
      when that happens. The manual specifies writing 0 to the counters
      after each read, but that's 1) too expensive, and 2) destroys the
      possibility of sharing these counters with other users, so we live
      with the blimp - the other existing user does too.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      47fe38fc
  23. 20 8月, 2009 1 次提交
  24. 14 3月, 2009 1 次提交
  25. 11 3月, 2009 1 次提交
  26. 25 12月, 2008 1 次提交
    • F
      tracing/ftrace: don't trace on early stage of a secondary cpu boot, v3 · 0ca59dd9
      Frederic Weisbecker 提交于
      Impact: fix a crash/hard-reboot on certain configs while enabling cpu runtime
      
      On some archs, the boot of a secondary cpu can have an early fragile state.
      On x86-64, the pda is not initialized on the first stage of a cpu boot but
      it is needed to get the cpu number and the current task pointer. This data
      is needed during tracing. As they were dereferenced at this stage, we got a
      crash while tracing a cpu being enabled at runtime.
      
      Some other archs like ia64 can have such kind of issue too.
      
      Changes on v2:
      
      We dropped the previous solution of a per-arch called function to guess the
      current state of a cpu. That could slow down the tracing.
      
      This patch removes the -pg flag on arch/x86/kernel/cpu/common.c where
      the low level cpu boot functions exist, on start_secondary() and a helper
      function used at this stage.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Acked-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0ca59dd9
  27. 08 12月, 2008 1 次提交
    • I
      performance counters: x86 support · 241771ef
      Ingo Molnar 提交于
      Implement performance counters for x86 Intel CPUs.
      
      It's simplified right now: the PERFMON CPU feature is assumed,
      which is available in Core2 and later Intel CPUs.
      
      The design is flexible to be extended to more CPU types as well.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      241771ef
  28. 02 11月, 2008 1 次提交
    • A
      x86: Hypervisor detection and get tsc_freq from hypervisor · 88b094fb
      Alok Kataria 提交于
      Impact: Changes timebase calibration on Vmware.
      
      v3->v2 : Abstract the hypervisor detection and feature (tsc_freq) request
      	 behind a hypervisor.c file
      v2->v1 : Add a x86_hyper_vendor field to the cpuinfo_x86 structure.
      	 This avoids multiple calls to the hypervisor detection function.
      
      This patch adds function to detect if we are running under VMware.
      The current way to check if we are on VMware is following,
      #  check if "hypervisor present bit" is set, if so read the 0x40000000
         cpuid leaf and check for "VMwareVMware" signature.
      #  if the above fails, check the DMI vendors name for "VMware" string
         if we find one we query the VMware hypervisor port to check if we are
         under VMware.
      
      The DMI + "VMware hypervisor port check" is needed for older VMware products,
      which don't implement the hypervisor signature cpuid leaf.
      Also note that since we are checking for the DMI signature the hypervisor
      port should never be accessed on native hardware.
      
      This patch also adds a hypervisor_get_tsc_freq function, instead of
      calibrating the frequency which can be error prone in virtualized
      environment, we ask the hypervisor for it. We get the frequency from
      the hypervisor by accessing the hypervisor port if we are running on VMware.
      Other hypervisors too can add code to the generic routine to get frequency on
      their platform.
      Signed-off-by: NAlok N Kataria <akataria@vmware.com>
      Signed-off-by: NDan Hecht <dhecht@vmware.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      88b094fb
  29. 23 10月, 2008 1 次提交
  30. 10 9月, 2008 1 次提交
  31. 08 9月, 2008 1 次提交
  32. 05 9月, 2008 2 次提交
  33. 28 8月, 2008 1 次提交
    • H
      x86: generate names for /proc/cpuinfo from <asm/cpufeature.h> · 7414aa41
      H. Peter Anvin 提交于
      We have had a number of cases where <asm/cpufeature.h> (and its
      predecessors) have diverged substantially from the names list in
      /proc/cpuinfo.  This patch generates the latter from the former.
      
      It retains the option for explicitly overriding the strings, but by
      making that require a separate action it should at least be less
      likely to happen.
      
      It would be good to do a future pass and rename strings that are
      gratuituously different in the kernel (/proc/cpuinfo is a userspace
      interface and must remain constant.)
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      7414aa41
  34. 18 8月, 2008 2 次提交
    • T
      x86: configuration options to compile out x86 CPU support code · 8d02c211
      Thomas Petazzoni 提交于
      This patch adds some configuration options that allow to compile out
      CPU vendor-specific code in x86 kernels (in arch/x86/kernel/cpu). The
      new configuration options are only visible when CONFIG_EMBEDDED is
      selected, as they are mostly interesting for space savings reasons.
      
      An example of size saving, on x86 with only Intel CPU support:
      
         text	   data	    bss	    dec	    hex	filename
      1125479	 118760	 212992	1457231	 163c4f	vmlinux.old
      1121355	 116536	 212992	1450883	 162383	vmlinux
        -4124   -2224       0   -6348   -18CC +/-
      
      However, I'm not exactly sure that the Kconfig wording is correct with
      regard to !64BIT / 64BIT.
      
      [ mingo@elte.hu: convert macro to inline ]
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d02c211
    • T
      x86: move cmpxchg fallbacks to a generic place · 774400a3
      Thomas Petazzoni 提交于
      arch/x86/kernel/cpu/intel.c defines a few fallback functions
      (cmpxchg_*()) that are used when the CPU doesn't support cmpxchg
      and/or cmpxchg64 natively. However, while defined in an Intel-specific
      file, these functions are also used for CPUs from other vendors when
      they don't support cmpxchg and/or cmpxchg64. This breaks the
      compilation when support for Intel CPUs is disabled.
      
      This patch moves these functions to a new
      arch/x86/kernel/cpu/cmpxchg.c file, unconditionally compiled when
      X86_32 is enabled.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: michael@free-electrons.com
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      774400a3
  35. 08 7月, 2008 1 次提交
  36. 04 6月, 2008 1 次提交
  37. 31 5月, 2008 1 次提交