1. 21 9月, 2019 1 次提交
  2. 15 5月, 2019 1 次提交
    • P
      x86/cpu: Sanitize FAM6_ATOM naming · 1f1bc822
      Peter Zijlstra 提交于
      commit f2c4db1bd80720cd8cb2a5aa220d9bc9f374f04e upstream
      
      Going primarily by:
      
        https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors
      
      with additional information gleaned from other related pages; notably:
      
       - Bonnell shrink was called Saltwell
       - Moorefield is the Merriefield refresh which makes it Airmont
      
      The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE
      
        for i in `git grep -l FAM6_ATOM` ; do
      	sed -i  -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g'		\
      		-e 's/ATOM_LINCROFT/ATOM_BONNELL_MID/'		\
      		-e 's/ATOM_PENWELL/ATOM_SALTWELL_MID/g'		\
      		-e 's/ATOM_CLOVERVIEW/ATOM_SALTWELL_TABLET/g'	\
      		-e 's/ATOM_CEDARVIEW/ATOM_SALTWELL/g'		\
      		-e 's/ATOM_SILVERMONT1/ATOM_SILVERMONT/g'	\
      		-e 's/ATOM_SILVERMONT2/ATOM_SILVERMONT_X/g'	\
      		-e 's/ATOM_MERRIFIELD/ATOM_SILVERMONT_MID/g'	\
      		-e 's/ATOM_MOOREFIELD/ATOM_AIRMONT_MID/g'	\
      		-e 's/ATOM_DENVERTON/ATOM_GOLDMONT_X/g'		\
      		-e 's/ATOM_GEMINI_LAKE/ATOM_GOLDMONT_PLUS/g' ${i}
        done
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: dave.hansen@linux.intel.com
      Cc: len.brown@intel.com
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f1bc822
  3. 20 4月, 2019 1 次提交
  4. 28 7月, 2018 2 次提交
  5. 27 7月, 2018 3 次提交
    • P
      tools/power turbostat: Fix logical node enumeration to allow for non-sequential physical nodes · 2ffbb224
      Prarit Bhargava 提交于
      turbostat fails on some multi-package topologies because the logical node
      enumeration assumes that the nodes are sequentially numbered,
      which causes the logical numa nodes to not be enumerated, or enumerated incorrectly.
      
      Use a more robust enumeration algorithm which allows for non-seqential physical nodes.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      2ffbb224
    • L
      tools/power turbostat: fix x2apic debug message output file · cfce494d
      Len Brown 提交于
      A recently added x2apic debug message was hard-coded to stderr.
      That doesn't work with "-o outfile".
      Signed-off-by: NLen Brown <len.brown@intel.com>
      cfce494d
    • A
      tools/power turbostat: fix bogus summary values · 4f206a0f
      Artem Bityutskiy 提交于
      This patch fixes a regression introduced in
      
      commit 8cb48b32 ("tools/power turbostat: track thread ID in cpu_topology")
      
      Turbostat uses incorrect cores number ('topo.num_cores') - its value is count
      of logical CPUs, instead of count of physical cores. So it is twice as large as
      it should be on a typical Intel system. For example, on a 6 core Xeon system
      'topo.num_cores' is 12, and on a 52 core Xeon system 'topo.num_cores' is 104.
      
      And interestingly, on a 68-core Knights Landing Intel system 'topo.num_cores'
      is 272, because this system has 4 logical CPUs per core.
      
      As a result, some of the turbostat calculations are incorrect. For example,
      on idle 52-core Xeon system when all cores are ~99% in Core C6 (CPU%c6), the
      summary (very first) line shows ~48% Core C6, while it should be ~99%.
      
      This patch fixes the problem by fixing 'topo.num_cores' calculation.
      
      Was:
      
      1. Init 'thread_id' for all CPUs to -1
      2. Run 'get_thread_siblings()' which sets it to 0 or 1
      3. Increment 'topo.num_cores' when thread_id != -1 (bug!)
      
      Now:
      
      1. Init 'thread_id' for all CPUs to -1
      2. Run 'get_thread_siblings()' which sets it to 0 or 1
      3. Increment 'topo.num_cores' when thread_id is not 0
      
      I did not have a chance to test this on an AMD machine, and only tested on a
      couple of Intel Xeons (6 and 52 cores).
      Reported-by: NVladislav Govtva <vladislav.govtva@intel.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      4f206a0f
  6. 21 7月, 2018 1 次提交
  7. 21 6月, 2018 8 次提交
  8. 02 6月, 2018 23 次提交