1. 19 9月, 2012 3 次提交
    • S
      x86, fpu: decouple non-lazy/eager fpu restore from xsave · 5d2bd700
      Suresh Siddha 提交于
      Decouple non-lazy/eager fpu restore policy from the existence of the xsave
      feature. Introduce a synthetic CPUID flag to represent the eagerfpu
      policy. "eagerfpu=on" boot paramter will enable the policy.
      Requested-by: NH. Peter Anvin <hpa@zytor.com>
      Requested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1347300665-6209-2-git-send-email-suresh.b.siddha@intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      5d2bd700
    • S
      x86, fpu: use non-lazy fpu restore for processors supporting xsave · 304bceda
      Suresh Siddha 提交于
      Fundamental model of the current Linux kernel is to lazily init and
      restore FPU instead of restoring the task state during context switch.
      This changes that fundamental lazy model to the non-lazy model for
      the processors supporting xsave feature.
      
      Reasons driving this model change are:
      
      i. Newer processors support optimized state save/restore using xsaveopt and
      xrstor by tracking the INIT state and MODIFIED state during context-switch.
      This is faster than modifying the cr0.TS bit which has serializing semantics.
      
      ii. Newer glibc versions use SSE for some of the optimized copy/clear routines.
      With certain workloads (like boot, kernel-compilation etc), application
      completes its work with in the first 5 task switches, thus taking upto 5 #DNA
      traps with the kernel not getting a chance to apply the above mentioned
      pre-load heuristic.
      
      iii. Some xstate features (like AMD's LWP feature) don't honor the cr0.TS bit
      and thus will not work correctly in the presence of lazy restore. Non-lazy
      state restore is needed for enabling such features.
      
      Some data on a two socket SNB system:
       * Saved 20K DNA exceptions during boot on a two socket SNB system.
       * Saved 50K DNA exceptions during kernel-compilation workload.
       * Improved throughput of the AVX based checksumming function inside the
         kernel by ~15% as xsave/xrstor is faster than the serializing clts/stts
         pair.
      
      Also now kernel_fpu_begin/end() relies on the patched
      alternative instructions. So move check_fpu() which uses the
      kernel_fpu_begin/end() after alternative_instructions().
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1345842782-24175-7-git-send-email-suresh.b.siddha@intel.com
      Merge 32-bit boot fix from,
      Link: http://lkml.kernel.org/r/1347300665-6209-4-git-send-email-suresh.b.siddha@intel.com
      Cc: Jim Kukunas <james.t.kukunas@linux.intel.com>
      Cc: NeilBrown <neilb@suse.de>
      Cc: Avi Kivity <avi@redhat.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      304bceda
    • S
      x86, fpu: Unify signal handling code paths for x86 and x86_64 kernels · 72a671ce
      Suresh Siddha 提交于
      Currently for x86 and x86_32 binaries, fpstate in the user sigframe is copied
      to/from the fpstate in the task struct.
      
      And in the case of signal delivery for x86_64 binaries, if the fpstate is live
      in the CPU registers, then the live state is copied directly to the user
      sigframe. Otherwise  fpstate in the task struct is copied to the user sigframe.
      During restore, fpstate in the user sigframe is restored directly to the live
      CPU registers.
      
      Historically, different code paths led to different bugs. For example,
      x86_64 code path was not preemption safe till recently. Also there is lot
      of code duplication for support of new features like xsave etc.
      
      Unify signal handling code paths for x86 and x86_64 kernels.
      
      New strategy is as follows:
      
      Signal delivery: Both for 32/64-bit frames, align the core math frame area to
      64bytes as needed by xsave (this where the main fpu/extended state gets copied
      to and excludes the legacy compatibility fsave header for the 32-bit [f]xsave
      frames). If the state is live, copy the register state directly to the user
      frame. If not live, copy the state in the thread struct to the user frame. And
      for 32-bit [f]xsave frames, construct the fsave header separately before
      the actual [f]xsave area.
      
      Signal return: As the 32-bit frames with [f]xstate has an additional
      'fsave' header, copy everything back from the user sigframe to the
      fpstate in the task structure and reconstruct the fxstate from the 'fsave'
      header (Also user passed pointers may not be correctly aligned for
      any attempt to directly restore any partial state). At the next fpstate usage,
      everything will be restored to the live CPU registers.
      For all the 64-bit frames and the 32-bit fsave frame, restore the state from
      the user sigframe directly to the live CPU registers. 64-bit signals always
      restored the math frame directly, so we can expect the math frame pointer
      to be correctly aligned. For 32-bit fsave frames, there are no alignment
      requirements, so we can restore the state directly.
      
      "lat_sig catch" microbenchmark numbers (for x86, x86_64, x86_32 binaries) are
      with in the noise range with this change.
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Link: http://lkml.kernel.org/r/1343171129-2747-4-git-send-email-suresh.b.siddha@intel.com
      [ Merged in compilation fix ]
      Link: http://lkml.kernel.org/r/1344544736.8326.17.camel@sbsiddha-desk.sc.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      72a671ce
  2. 06 6月, 2012 1 次提交
  3. 17 5月, 2012 2 次提交
  4. 15 5月, 2012 1 次提交
  5. 09 5月, 2012 1 次提交
  6. 08 5月, 2012 2 次提交
  7. 07 5月, 2012 1 次提交
    • S
      x86/sched: Make mwait_usable() heed to "idle=" kernel parameters properly · 19209bbb
      Srivatsa S. Bhat 提交于
      The checks that exist in mwait_usable() for "idle=" kernel
      parameters are insufficient. As a result, mwait_usable() can
      return 1 even if "idle=nomwait" or "idle=poll" or "idle=halt"
      parameters are passed.
      
      Of these cases, incorrect handling of idle=nomwait is a
      universal problem since mwait can get used for usual CPU idling.
      However the rest of the cases are problematic only during CPU
      Hotplug (offline) because, in the CPU offline path, the function
      mwait_play_dead() is called, which might result in mwait being
      used in the offline CPUs, if mwait_usable() happens to return 1.
      
      Fix these issues by checking for the boot time "idle=" kernel
      parameter properly in mwait_usable().
      
      The first issue (usual cpu idling) is demonstrated below:
      
      Before applying the patch (dmesg snippet):
      
       [    0.000000] Command line: [...] idle=nomwait
       [    0.000000] Kernel command line: [...] idle=nomwait
       [    0.000000]  RCU dyntick-idle grace-period acceleration is enabled.
       [    0.140606] using mwait in idle threads.  <======= mwait being used
       [    4.303986] cpuidle: using governor ladder
       [    4.308232] cpuidle: using governor menu
      
      After applying the patch:
      
       [    0.000000] Command line: [...] idle=nomwait
       [    0.000000] Kernel command line: [...] idle=nomwait
       [    0.000000]  RCU dyntick-idle grace-period acceleration is enabled.
       [    4.264100] cpuidle: using governor ladder
       [    4.268342] cpuidle: using governor menu
      Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
      Acked-by: NDeepthi Dharwar <deepthi@linux.vnet.ibm.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: venki@google.com
      Cc: suresh.b.siddha@intel.com
      Cc: Borislav Petkov <bp@amd64.org>
      Cc: lenb@kernel.org
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Link: http://lkml.kernel.org/r/4F9E37B8.30001@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      19209bbb
  8. 05 5月, 2012 1 次提交
  9. 30 3月, 2012 1 次提交
    • L
      x86: Remove the ancient and deprecated disable_hlt() and enable_hlt() facility · f6365201
      Len Brown 提交于
      The X86_32-only disable_hlt/enable_hlt mechanism was used by the
      32-bit floppy driver. Its effect was to replace the use of the
      HLT instruction inside default_idle() with cpu_relax() - essentially
      it turned off the use of HLT.
      
      This workaround was commented in the code as:
      
       "disable hlt during certain critical i/o operations"
      
       "This halt magic was a workaround for ancient floppy DMA
        wreckage. It should be safe to remove."
      
      H. Peter Anvin additionally adds:
      
       "To the best of my knowledge, no-hlt only existed because of
        flaky power distributions on 386/486 systems which were sold to
        run DOS.  Since DOS did no power management of any kind,
        including HLT, the power draw was fairly uniform; when exposed
        to the much hhigher noise levels you got when Linux used HLT
        caused some of these systems to fail.
      
        They were by far in the minority even back then."
      
      Alan Cox further says:
      
       "Also for the Cyrix 5510 which tended to go castors up if a HLT
        occurred during a DMA cycle and on a few other boxes HLT during
        DMA tended to go astray.
      
        Do we care ? I doubt it. The 5510 was pretty obscure, the 5520
        fixed it, the 5530 is probably the oldest still in any kind of
        use."
      
      So, let's finally drop this.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Acked-by: N"H. Peter Anvin" <hpa@zytor.com>
      Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Stephen Hemminger <shemminger@vyatta.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <stable@kernel.org>
      Link: http://lkml.kernel.org/n/tip-3rhk9bzf0x9rljkv488tloib@git.kernel.org
      [ If anyone cares then alternative instruction patching could be
        used to replace HLT with a one-byte NOP instruction. Much simpler. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      f6365201
  10. 29 3月, 2012 1 次提交
  11. 26 3月, 2012 1 次提交
  12. 22 2月, 2012 1 次提交
    • L
      i387: Split up <asm/i387.h> into exported and internal interfaces · 1361b83a
      Linus Torvalds 提交于
      While various modules include <asm/i387.h> to get access to things we
      actually *intend* for them to use, most of that header file was really
      pretty low-level internal stuff that we really don't want to expose to
      others.
      
      So split the header file into two: the small exported interfaces remain
      in <asm/i387.h>, while the internal definitions that are only used by
      core architecture code are now in <asm/fpu-internal.h>.
      
      The guiding principle for this was to expose functions that we export to
      modules, and leave them in <asm/i387.h>, while stuff that is used by
      task switching or was marked GPL-only is in <asm/fpu-internal.h>.
      
      The fpu-internal.h file could be further split up too, especially since
      arch/x86/kvm/ uses some of the remaining stuff for its module.  But that
      kvm usage should probably be abstracted out a bit, and at least now the
      internal FPU accessor functions are much more contained.  Even if it
      isn't perhaps as contained as it _could_ be.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1202211340330.5354@i5.linux-foundation.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      1361b83a
  13. 13 2月, 2012 1 次提交
  14. 06 12月, 2011 1 次提交
    • S
      x86: Fix rflags in FAKE_STACK_FRAME · 1cf8343f
      Seiichi Ikarashi 提交于
      The x86_64 kernel pushes the fake kernel stack in
      arch/x86/kernel/entry_64.S:FAKE_STACK_FRAME, and
      rflags register in it does not conform to the specification.
      
      Although Intel's manual[1] says bit 1 of it shall be set to 1,
      this bit is cleared to 0 on pushing the fake stack.
      
      [1] Intel(R) 64 and IA-32 Architectures Software Developer's Manual
          Vol.1 3-21 Figure 3-8. EFLAGS Register
      
      If it is not on purpose, it is better to be fixed, because
      it can lead some tools misunderstanding the stack frame. For example,
      "crash" utility[2] actually detects it and warns you like
      below:
      
             RIP: ffffffff8005dfa2  RSP: ffff8104ce0c7f58  RFLAGS: 00000200
             [...]
      
             bt: WARNING: possibly bogus exception frame
      Signed-off-by: NSeiichi Ikarashi <s.ikarashi@jp.fujitsu.com>
      Tested-by: NMasayoshi MIZUMA <m.mizuma@jp.fujitsu.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1cf8343f
  15. 04 12月, 2011 1 次提交
    • K
      xen/pm_idle: Make pm_idle be default_idle under Xen. · e5fd47bf
      Konrad Rzeszutek Wilk 提交于
      The idea behind commit d91ee586 ("cpuidle: replace xen access to x86
      pm_idle and default_idle") was to have one call - disable_cpuidle()
      which would make pm_idle not be molested by other code.  It disallows
      cpuidle_idle_call to be set to pm_idle (which is excellent).
      
      But in the select_idle_routine() and idle_setup(), the pm_idle can still
      be set to either: amd_e400_idle, mwait_idle or default_idle.  This
      depends on some CPU flags (MWAIT) and in AMD case on the type of CPU.
      
      In case of mwait_idle we can hit some instances where the hypervisor
      (Amazon EC2 specifically) sets the MWAIT and we get:
      
        Brought up 2 CPUs
        invalid opcode: 0000 [#1] SMP
      
        Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
        RIP: e030:[<ffffffff81015d1d>]  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
        ...
        Call Trace:
         [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
         [<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10
        RIP  [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
         RSP <ffff8801d28ddf10>
      
      In the case of amd_e400_idle we don't get so spectacular crashes, but we
      do end up making an MSR which is trapped in the hypervisor, and then
      follow it up with a yield hypercall.  Meaning we end up going to
      hypervisor twice instead of just once.
      
      The previous behavior before v3.0 was that pm_idle was set to
      default_idle regardless of select_idle_routine/idle_setup.
      
      We want to do that, but only for one specific case: Xen.  This patch
      does that.
      
      Fixes RH BZ #739499 and Ubuntu #881076
      Reported-by: NStefan Bader <stefan.bader@canonical.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e5fd47bf
  16. 24 8月, 2011 1 次提交
  17. 04 8月, 2011 1 次提交
  18. 15 6月, 2011 1 次提交
  19. 30 5月, 2011 1 次提交
  20. 29 5月, 2011 3 次提交
    • L
      x86 idle: deprecate mwait_idle() and "idle=mwait" cmdline param · 5d4c47e0
      Len Brown 提交于
      mwait_idle() is a C1-only idle loop intended to be more efficient
      than HLT on SMP hardware that supports it.
      
      But mwait_idle() has been replaced by the more general
      mwait_idle_with_hints(), which handles both C1 and deeper C-states.
      ACPI uses only mwait_idle_with_hints(), and never uses mwait_idle().
      
      Deprecate mwait_idle() and the "idle=mwait" cmdline param
      to simplify the x86 idle code.
      
      After this change, kernels configured with
      (!CONFIG_ACPI=n && !CONFIG_INTEL_IDLE=n) when run on hardware
      that support MWAIT will simply use HLT.  If MWAIT is desired
      on those systems, cpuidle and the cpuidle drivers above
      can be used.
      
      cc: x86@kernel.org
      cc: stable@kernel.org # .39.x
      Signed-off-by: NLen Brown <len.brown@intel.com>
      5d4c47e0
    • L
      x86 idle: EXPORT_SYMBOL(default_idle, pm_idle) only when APM demands it · 06ae40ce
      Len Brown 提交于
      In the long run, we don't want default_idle() or (pm_idle)() to
      be exported outside of process.c.  Start by not exporting them
      to modules, unless the APM build demands it.
      
      cc: x86@kernel.org
      cc: Jiri Kosina <jkosina@suse.cz>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      06ae40ce
    • L
      x86 idle: clarify AMD erratum 400 workaround · 02c68a02
      Len Brown 提交于
      The workaround for AMD erratum 400 uses the term "c1e" falsely suggesting:
      1. Intel C1E is somehow involved
      2. All AMD processors with C1E are involved
      
      Use the string "amd_c1e" instead of simply "c1e" to clarify that
      this workaround is specific to AMD's version of C1E.
      Use the string "e400" to clarify that the workaround is specific
      to AMD processors with Erratum 400.
      
      This patch is text-substitution only, with no functional change.
      
      cc: x86@kernel.org
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      02c68a02
  21. 29 3月, 2011 1 次提交
    • C
      x86: A fast way to check capabilities of the current cpu · 349c004e
      Christoph Lameter 提交于
      Add this_cpu_has() which determines if the current cpu has a certain
      ability using a segment prefix and a bit test operation.
      
      For that we need to add bit operations to x86s percpu.h.
      
      Many uses of cpu_has use a pointer passed to a function to determine
      the current flags. That is no longer necessary after this patch.
      
      However, this patch only converts the straightforward cases where
      cpu_has is used with this_cpu_ptr. The rest is work for later.
      
      -tj: Rolled up patch to add x86_ prefix and use percpu_read() instead
           of percpu_read_stable().
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      349c004e
  22. 18 3月, 2011 1 次提交
    • N
      x86, dumpstack: Correct stack dump info when frame pointer is available · e8e999cf
      Namhyung Kim 提交于
      Current stack dump code scans entire stack and check each entry
      contains a pointer to kernel code. If CONFIG_FRAME_POINTER=y it
      could mark whether the pointer is valid or not based on value of
      the frame pointer. Invalid entries could be preceded by '?' sign.
      
      However this was not going to happen because scan start point
      was always higher than the frame pointer so that they could not
      meet.
      
      Commit 9c0729dc ("x86: Eliminate bp argument from the stack
      tracing routines") delayed bp acquisition point, so the bp was
      read in lower frame, thus all of the entries were marked
      invalid.
      
      This patch fixes this by reverting above commit while retaining
      stack_frame() helper as suggested by Frederic Weisbecker.
      
      End result looks like below:
      
      before:
      
       [    3.508329] Call Trace:
       [    3.508551]  [<ffffffff814f35c9>] ? panic+0x91/0x199
       [    3.508662]  [<ffffffff814f3739>] ? printk+0x68/0x6a
       [    3.508770]  [<ffffffff81a981b2>] ? mount_block_root+0x257/0x26e
       [    3.508876]  [<ffffffff81a9821f>] ? mount_root+0x56/0x5a
       [    3.508975]  [<ffffffff81a98393>] ? prepare_namespace+0x170/0x1a9
       [    3.509216]  [<ffffffff81a9772b>] ? kernel_init+0x1d2/0x1e2
       [    3.509335]  [<ffffffff81003894>] ? kernel_thread_helper+0x4/0x10
       [    3.509442]  [<ffffffff814f6880>] ? restore_args+0x0/0x30
       [    3.509542]  [<ffffffff81a97559>] ? kernel_init+0x0/0x1e2
       [    3.509641]  [<ffffffff81003890>] ? kernel_thread_helper+0x0/0x10
      
      after:
      
       [    3.522991] Call Trace:
       [    3.523351]  [<ffffffff814f35b9>] panic+0x91/0x199
       [    3.523468]  [<ffffffff814f3729>] ? printk+0x68/0x6a
       [    3.523576]  [<ffffffff81a981b2>] mount_block_root+0x257/0x26e
       [    3.523681]  [<ffffffff81a9821f>] mount_root+0x56/0x5a
       [    3.523780]  [<ffffffff81a98393>] prepare_namespace+0x170/0x1a9
       [    3.523885]  [<ffffffff81a9772b>] kernel_init+0x1d2/0x1e2
       [    3.523987]  [<ffffffff81003894>] kernel_thread_helper+0x4/0x10
       [    3.524228]  [<ffffffff814f6880>] ? restore_args+0x0/0x30
       [    3.524345]  [<ffffffff81a97559>] ? kernel_init+0x0/0x1e2
       [    3.524445]  [<ffffffff81003890>] ? kernel_thread_helper+0x0/0x10
      
       -v5:
         * fix build breakage with oprofile
      
       -v4:
         * use 0 instead of regs->bp
         * separate out printk changes
      
       -v3:
         * apply comment from Frederic
         * add a couple of printk fixes
      Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Soren Sandmann <ssp@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Robert Richter <robert.richter@amd.com>
      LKML-Reference: <1300416006-3163-1-git-send-email-namhyung@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e8e999cf
  23. 18 2月, 2011 1 次提交
  24. 15 2月, 2011 1 次提交
    • N
      x86, dmi, debug: Log board name (when present) in dmesg/oops output · 84e383b3
      Naga Chumbalkar 提交于
      The "Type 2" SMBIOS record that contains Board Name is not
      strictly required and may be absent in the SMBIOS on some
      platforms.
      
      ( Please note that Type 2 is not listed in Table 3 in Sec 6.2
        ("Required Structures and Data") of the SMBIOS v2.7
        Specification. )
      
      Use the Manufacturer Name (aka System Vendor) name.
      Print Board Name only when it is present.
      
      Before the fix:
        (i) dmesg output: DMI: /ProLiant DL380 G6, BIOS P62 01/29/2011
       (ii) oops output:  Pid: 2170, comm: bash Not tainted 2.6.38-rc4+ #3 /ProLiant DL380 G6
      
      After the fix:
        (i) dmesg output: DMI: HP ProLiant DL380 G6, BIOS P62 01/29/2011
       (ii) oops output:  Pid: 2278, comm: bash Not tainted 2.6.38-rc4+ #4 HP ProLiant DL380 G6
      Signed-off-by: NNaga Chumbalkar <nagananda.chumbalkar@hp.com>
      Reviewed-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: <stable@kernel.org> # .3x - good for debugging, please apply as far back as it applies cleanly
      LKML-Reference: <20110214224423.2182.13929.sendpatchset@nchumbalkar.americas.hpqcorp.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      84e383b3
  25. 14 2月, 2011 1 次提交
  26. 22 1月, 2011 1 次提交
    • B
      x86, hotplug: Fix powersavings with offlined cores on AMD · 93789b32
      Borislav Petkov 提交于
      ea530692 made a CPU use monitor/mwait
      when offline. This is not the optimal choice for AMD wrt to powersavings
      and we'd prefer our cores to halt (i.e. enter C1) instead. For this, the
      same selection whether to use monitor/mwait has to be used as when we
      select the idle routine for the machine.
      
      With this patch, offlining cores 1-5 on a X6 machine allows core0 to
      boost again.
      
      [ hpa: putting this in urgent since it is a (power) regression fix ]
      Reported-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: stable@kernel.org # 37.x
      Cc: H. Peter Anvin <hpa@linux.intel.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Venkatesh Pallipadi <venki@google.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.hl>
      Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
      LKML-Reference: <1295534572-10730-1-git-send-email-bp@amd64.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      93789b32
  27. 13 1月, 2011 2 次提交
    • T
      cpuidle/x86/perf: fix power:cpu_idle double end events and throw cpu_idle... · f77cfe4e
      Thomas Renninger 提交于
      cpuidle/x86/perf: fix power:cpu_idle double end events and throw cpu_idle events from the cpuidle layer
      
      Currently intel_idle and acpi_idle driver show double cpu_idle "exit idle"
      events -> this patch fixes it and makes cpu_idle events throwing less complex.
      
      It also introduces cpu_idle events for all architectures which use
      the cpuidle subsystem, namely:
        - arch/arm/mach-at91/cpuidle.c
        - arch/arm/mach-davinci/cpuidle.c
        - arch/arm/mach-kirkwood/cpuidle.c
        - arch/arm/mach-omap2/cpuidle34xx.c
        - arch/drivers/acpi/processor_idle.c (for all cases, not only mwait)
        - arch/x86/kernel/process.c (did throw events before, but was a mess)
        - drivers/idle/intel_idle.c (did throw events before)
      
      Convention should be:
      Fire cpu_idle events inside the current pm_idle function (not somewhere
      down the the callee tree) to keep things easy.
      
      Current possible pm_idle functions in X86:
      c1e_idle, poll_idle, cpuidle_idle_call, mwait_idle, default_idle
      -> this is really easy is now.
      
      This affects userspace:
      The type field of the cpu_idle power event can now direclty get
      mapped to:
      /sys/devices/system/cpu/cpuX/cpuidle/stateX/{name,desc,usage,time,...}
      instead of throwing very CPU/mwait specific values.
      This change is not visible for the intel_idle driver.
      For the acpi_idle driver it should only be visible if the vendor
      misses out C-states in his BIOS.
      Another (perf timechart) patch reads out cpuidle info of cpu_idle
      events from:
      /sys/.../cpuidle/stateX/*, then the cpuidle events are mapped
      to the correct C-/cpuidle state again, even if e.g. vendors miss
      out C-states in their BIOS and for example only export C1 and C3.
      -> everything is fine.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      CC: Robert Schoene <robert.schoene@tu-dresden.de>
      CC: Jean Pihet <j-pihet@ti.com>
      CC: Arjan van de Ven <arjan@linux.intel.com>
      CC: Ingo Molnar <mingo@elte.hu>
      CC: Frederic Weisbecker <fweisbec@gmail.com>
      CC: linux-pm@lists.linux-foundation.org
      CC: linux-acpi@vger.kernel.org
      CC: linux-kernel@vger.kernel.org
      CC: linux-perf-users@vger.kernel.org
      CC: linux-omap@vger.kernel.org
      Signed-off-by: NLen Brown <len.brown@intel.com>
      f77cfe4e
    • T
      ACPI, intel_idle: Cleanup idle= internal variables · d1896049
      Thomas Renninger 提交于
      Having four variables for the same thing:
        idle_halt, idle_nomwait, force_mwait and boot_option_idle_overrides
      is rather confusing and unnecessary complex.
      
      if idle= boot param is passed, only set up one variable:
      boot_option_idle_overrides
      
      Introduces following functional changes/fixes:
        - intel_idle driver does not register if any idle=xy
          boot param is passed.
        - processor_idle.c will also not register a cpuidle driver
          and get active if idle=halt is passed.
          Before a cpuidle driver with one (C1, halt) state got registered
          Now the default_idle function will be used which finally uses
          the same idle call to enter sleep state (safe_halt()), but
          without registering a whole cpuidle driver.
      
      That means idle= param will always avoid cpuidle drivers to register
      with one exception (same behavior as before):
      idle=nomwait
      may still register acpi_idle cpuidle driver, but C1 will not use
      mwait, but hlt. This can be a workaround for IO based deeper sleep
      states where C1 mwait causes problems.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      cc: x86@kernel.org
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d1896049
  28. 04 1月, 2011 1 次提交
    • T
      perf: Clean up power events by introducing new, more generic ones · 25e41933
      Thomas Renninger 提交于
      Add these new power trace events:
      
       power:cpu_idle
       power:cpu_frequency
       power:machine_suspend
      
      The old C-state/idle accounting events:
        power:power_start
        power:power_end
      
      Have now a replacement (but we are still keeping the old
      tracepoints for compatibility):
      
        power:cpu_idle
      
      and
        power:power_frequency
      
      is replaced with:
        power:cpu_frequency
      
      power:machine_suspend is newly introduced.
      
      Jean Pihet has a patch integrated into the generic layer
      (kernel/power/suspend.c) which will make use of it.
      
      the type= field got removed from both, it was never
      used and the type is differed by the event type itself.
      
      perf timechart userspace tool gets adjusted in a separate patch.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NArjan van de Ven <arjan@linux.intel.com>
      Acked-by: NJean Pihet <jean.pihet@newoldbits.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: rjw@sisk.pl
      LKML-Reference: <1294073445-14812-3-git-send-email-trenn@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      LKML-Reference: <1290072314-31155-2-git-send-email-trenn@suse.de>
      25e41933
  29. 30 12月, 2010 1 次提交
  30. 18 11月, 2010 1 次提交
    • S
      x86: Eliminate bp argument from the stack tracing routines · 9c0729dc
      Soeren Sandmann Pedersen 提交于
      The various stack tracing routines take a 'bp' argument in which the
      caller is supposed to provide the base pointer to use, or 0 if doesn't
      have one. Since bp is garbage whenever CONFIG_FRAME_POINTER is not
      defined, this means all callers in principle should either always pass
      0, or be conditional on CONFIG_FRAME_POINTER.
      
      However, there are only really three use cases for stack tracing:
      
      (a) Trace the current task, including IRQ stack if any
      (b) Trace the current task, but skip IRQ stack
      (c) Trace some other task
      
      In all cases, if CONFIG_FRAME_POINTER is not defined, bp should just
      be 0.  If it _is_ defined, then
      
      - in case (a) bp should be gotten directly from the CPU's register, so
        the caller should pass NULL for regs,
      
      - in case (b) the caller should should pass the IRQ registers to
        dump_trace(),
      
      - in case (c) bp should be gotten from the top of the task's stack, so
        the caller should pass NULL for regs.
      
      Hence, the bp argument is not necessary because the combination of
      task and regs is sufficient to determine an appropriate value for bp.
      
      This patch introduces a new inline function stack_frame(task, regs)
      that computes the desired bp. This function is then called from the
      two versions of dump_stack().
      Signed-off-by: NSoren Sandmann <ssp@redhat.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arjan van de Ven <arjan@infradead.org>,
      Cc: Frederic Weisbecker <fweisbec@gmail.com>,
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
      LKML-Reference: <m3oc9rop28.fsf@dhcp-100-3-82.bos.redhat.com>>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      9c0729dc
  31. 18 8月, 2010 1 次提交
    • D
      Make do_execve() take a const filename pointer · d7627467
      David Howells 提交于
      Make do_execve() take a const filename pointer so that kernel_execve() compiles
      correctly on ARM:
      
      arch/arm/kernel/sys_arm.c:88: warning: passing argument 1 of 'do_execve' discards qualifiers from pointer target type
      
      This also requires the argv and envp arguments to be consted twice, once for
      the pointer array and once for the strings the array points to.  This is
      because do_execve() passes a pointer to the filename (now const) to
      copy_strings_kernel().  A simpler alternative would be to cast the filename
      pointer in do_execve() when it's passed to copy_strings_kernel().
      
      do_execve() may not change any of the strings it is passed as part of the argv
      or envp lists as they are some of them in .rodata, so marking these strings as
      const should be fine.
      
      Further kernel_execve() and sys_execve() need to be changed to match.
      
      This has been test built on x86_64, frv, arm and mips.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Tested-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d7627467
  32. 14 8月, 2010 1 次提交
  33. 04 8月, 2010 1 次提交
    • T
      [CPUFREQ] x86 cpufreq: Make trace_power_frequency cpufreq driver independent · 6f4f2723
      Thomas Renninger 提交于
      and fix the broken case if a core's frequency depends on others.
      
      trace_power_frequency was only implemented in a rather ungeneric way
      in acpi-cpufreq driver's target() function only.
      -> Move the call to trace_power_frequency to
         cpufreq.c:cpufreq_notify_transition() where CPUFREQ_POSTCHANGE
         notifier is triggered.
         This will support power frequency tracing by all cpufreq drivers
      
      trace_power_frequency did not trace frequency changes correctly when
      the userspace governor was used or when CPU cores' frequency depend
      on each other.
      -> Moving this into the CPUFREQ_POSTCHANGE notifier and pass the cpu
         which gets switched automatically fixes this.
      
      Robert Schoene provided some important fixes on top of my initial
      quick shot version which are integrated in this patch:
      - Forgot some changes in power_end trace (TP_printk/variable names)
      - Variable dummy in power_end must now be cpu_id
      - Use static 64 bit variable instead of unsigned int for cpu_id
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      CC: davej@redhat.com
      CC: arjan@infradead.org
      CC: linux-kernel@vger.kernel.org
      CC: robert.schoene@tu-dresden.de
      Tested-by: robert.schoene@tu-dresden.de
      Signed-off-by: NDave Jones <davej@redhat.com>
      6f4f2723