1. 02 Oct, 2018 1 commit
    • Peter Zijlstra's avatar
      x86/cpu: Sanitize FAM6_ATOM naming · f2c4db1b
      Peter Zijlstra authored
      Going primarily by:
      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'		\
      Signed-off-by: default avatarPeter 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: default avatarIngo Molnar <mingo@kernel.org>
  2. 10 Sep, 2018 1 commit
  3. 09 Nov, 2017 1 commit
  4. 04 Nov, 2017 1 commit
    • Andy Lutomirski's avatar
      Revert "x86/mm: Stop calling leave_mm() in idle code" · 67535736
      Andy Lutomirski authored
      This reverts commit 43858b4f.
      The reason I removed the leave_mm() calls in question is because the
      heuristic wasn't needed after that patch.  With the original version
      of my PCID series, we never flushed a "lazy cpu" (i.e. a CPU running
      kernel thread) due a flush on the loaded mm.
      Unfortunately, that caused architectural issues, so now I've
      reinstated these flushes on non-PCID systems in:
          commit b956575b ("x86/mm: Flush more aggressively in lazy TLB mode").
      That, in turn, gives us a power management and occasionally
      performance regression as compared to old kernels: a process that
      goes into a deep idle state on a given CPU and gets its mm flushed
      due to activity on a different CPU will wake the idle CPU.
      Reinstate the old ugly heuristic: if a CPU goes into ACPI C3 or an
      intel_idle state that is likely to cause a TLB flush gets its mm
      switched to init_mm before going idle.
      FWIW, this heuristic is lousy.  Whether we should change CR3 before
      idle isn't a good hint except insofar as the performance hit is a bit
      lower if the TLB is getting flushed by the idle code anyway.  What we
      really want to know is whether we anticipate being idle long enough
      that the mm is likely to be flushed before we wake up.  This is more a
      matter of the expected latency than the idle state that gets chosen.
      This heuristic also completely fails on systems that don't know
      whether the TLB will be flushed (e.g. AMD systems?).  OTOH it may be a
      bit obsolete anyway -- PCID systems don't presently benefit from this
      heuristic at all.
      We also shouldn't do this callback from innermost bit of the idle code
      due to the RCU nastiness it causes.  All the information need is
      available before rcu_idle_enter() needs to happen.
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bpetkov@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 43858b4f "x86/mm: Stop calling leave_mm() in idle code"
      Link: http://lkml.kernel.org/r/c513bbd4e653747213e05bc7062de000bf0202a5.1509793738.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  5. 11 Oct, 2017 1 commit
  6. 30 Aug, 2017 1 commit
  7. 10 Aug, 2017 1 commit
  8. 05 Jul, 2017 1 commit
  9. 29 Jun, 2017 1 commit
  10. 01 May, 2017 1 commit
  11. 01 Mar, 2017 1 commit
  12. 28 Feb, 2017 1 commit
    • Len Brown's avatar
      intel_idle: stop exposing platform acronyms in sysfs · de09cdd0
      Len Brown authored
      Cosmetic only -- no functional change in this patch.
      sysfs before:
      state4/desc:MWAIT 0x20
      sysfs after:
      state4/desc:MWAIT 0x20
      We remove the platform acronyms from the end of the state name
      (-HSW in this case) for three reasonse.
       1. more consistency with acpi_idle, which prints C1, C2, C3 etc.
       2. users know what platform they are on already
          an acronym for the processor code name here
          seems to cause more confusion than clarity.
       3. less clutter in "cpupower monitor" output,
          which truncates the names to 4 columns.
      The precise definition of the state continues to be available in "desc".
      Reported-by: default avatarArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  13. 01 Dec, 2016 4 commits
  14. 18 Nov, 2016 1 commit
  15. 08 Oct, 2016 1 commit
  16. 08 Jul, 2016 2 commits
  17. 01 Jul, 2016 1 commit
  18. 23 Jun, 2016 2 commits
    • Jacob Pan's avatar
      idle_intel: Add Denverton · 0080d65b
      Jacob Pan authored
      Denverton is an Intel Atom based micro server which shares the same
      Goldmont architecture as Broxton. The available C-states on
      Denverton is a subset of Broxton with only C1, C1e, and C6.
      Signed-off-by: default avatarJacob Pan <jacob.jun.pan@linux.intel.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
    • Paul Gortmaker's avatar
      drivers/idle: make intel_idle.c driver more explicitly non-modular · 02c4fae9
      Paul Gortmaker authored
      The Kconfig for this driver is currently declared with:
      config INTEL_IDLE
              bool "Cpuidle Driver for Intel Processors"
      ...meaning that it currently is not being built as a module by anyone.
      This was done in commit 6ce9cd86
      ("intel_idle: disable module support") since "...the module capability
      is cauing more trouble than it is worth."
      This was done over 5y ago, and Daniel adds that:
          ...the modular support has been removed from almost all the cpuidle
          drivers and the cpuidle framework is no longer assuming driver could
          be unloaded.
          Removing the modular dead code in the driver makes sense as this
          what have been done in the others drivers.
      So lets remove the modular code that is essentially orphaned, so that
      when reading the driver there is no doubt it is builtin-only.
      Since module_init translates to device_initcall in the non-modular
      case, the init ordering remains unchanged with this commit.  At a
      later date we might want to consider whether subsys_init or another
      init category seems more appropriate than device_init.
      We replace module.h with moduleparam.h since the file does declare
      some module parameters, and leaving them as such is currently the
      easiest way to remain compatible with existing boot arg use cases.
      Note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
      Also note that we can't remove intel_idle_cpuidle_devices_uninit() as
      that is still used for unwind purposes if the init fails.
      We also delete the MODULE_LICENSE tag etc. since all that information
      is already contained at the top of the file in the comments.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  19. 08 Jun, 2016 1 commit
    • Dave Hansen's avatar
      x86/intel_idle: Use Intel family macros for intel_idle · db73c5a8
      Dave Hansen authored
      Use the new INTEL_FAM6_* macros for intel_idle.c.  Also fix up
      some of the macros to be consistent with how some of the
      intel_idle code refers to the model.
      There's on oddity here: model 0x1F is uniquely referred to here
      and nowhere else that I could find.  0x1E/0x1F are just spelled
      out as "Intel Core i7 and i5 Processors" in the SDM or as "Intel
      processors based on the Nehalem, Westmere microarchitectures" in
      the RDPMC section.  Comments between tables 19-19 and 19-20 in
      the SDM seem to point to 0x1F being some kind of Westmere, so
      let's call it "WESTMERE2".
      Signed-off-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: jacob.jun.pan@intel.com
      Cc: linux-pm@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160603001932.EE978EB9@viggo.jf.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  20. 09 Apr, 2016 1 commit
  21. 07 Apr, 2016 12 commits
  22. 23 Mar, 2016 2 commits
  23. 10 Sep, 2015 1 commit