1. 30 4月, 2017 1 次提交
  2. 22 1月, 2017 1 次提交
    • J
      x86/timer: Make delay() work during early bootup · 4c45c516
      Jiri Slaby 提交于
      When a panic happens during bootup, "Rebooting in X seconds.." is
      shown, but reboot happens immediatelly. It is because panic() uses mdelay()
      and mdelay() calls __const_udelay() immediately, which does not
      work while booting.
      
      The per_cpu cpu_info.loops_per_jiffy value is not initialized yet, so
      __const_udelay() actually multiplies the number of loops by zero. This
      results in __const_udelay() to delay the execution only by a nanosecond
      or so.
      
      So check whether cpu_info.loops_per_jiffy is zero and use
      loops_per_jiffy in that case. mdelay() will not be so precise without
      proper calibration, but it works relatively well.
      
      Before:
      
        [    0.170039] delaying 100ms
        [    0.170828] done
      
      After
      
        [    0.214042] delaying 100ms
        [    0.313974] done
      
      I do not think the added check matters given we are about to spin the
      processor in the next few hundred cycles.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20170119114730.2670-1-jslaby@suse.cz
      [ Minor edits. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      4c45c516
  3. 14 7月, 2016 1 次提交
    • P
      x86/lib: Audit and remove any unnecessary uses of module.h · e683014c
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  The advantage
      in doing so is that module.h itself sources about 15 other headers;
      adding significantly to what we feed cpp, and it can obscure what
      headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each obj-y/bool instance
      for the presence of either and replace as needed.  Build testing
      revealed a couple implicit header usage issues that were fixed.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20160714001901.31603-5-paul.gortmaker@windriver.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      e683014c
  4. 10 3月, 2016 1 次提交
    • B
      x86/delay: Avoid preemptible context checks in delay_mwaitx() · 84477336
      Borislav Petkov 提交于
      We do use this_cpu_ptr(&cpu_tss) as a cacheline-aligned, seldomly
      accessed per-cpu var as the MONITORX target in delay_mwaitx(). However,
      when called in preemptible context, this_cpu_ptr -> smp_processor_id() ->
      debug_smp_processor_id() fires:
      
        BUG: using smp_processor_id() in preemptible [00000000] code: udevd/312
        caller is delay_mwaitx+0x40/0xa0
      
      But we don't care about that check - we only need cpu_tss as a MONITORX
      target and it doesn't really matter which CPU's var we're touching as
      we're going idle anyway. Fix that.
      Suggested-by: NAndy Lutomirski <luto@kernel.org>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Huang Rui <ray.huang@amd.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: spg_linux_kernel@amd.com
      Link: http://lkml.kernel.org/r/20160309205622.GG6564@pd.tnicSigned-off-by: NIngo Molnar <mingo@kernel.org>
      84477336
  5. 22 8月, 2015 1 次提交
    • H
      x86/asm/delay: Introduce an MWAITX-based delay with a configurable timer · b466bdb6
      Huang Rui 提交于
      MWAITX can enable a timer and a corresponding timer value
      specified in SW P0 clocks. The SW P0 frequency is the same as
      TSC. The timer provides an upper bound on how long the
      instruction waits before exiting.
      
      This way, a delay function in the kernel can leverage that
      MWAITX timer of MWAITX.
      
      When a CPU core executes MWAITX, it will be quiesced in a
      waiting phase, diminishing its power consumption. This way, we
      can save power in comparison to our default TSC-based delays.
      
      A simple test shows that:
      
      	$ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
      	$ sleep 10000s
      	$ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
      
      Results:
      
      	* TSC-based default delay:      485115 uWatts average power
      	* MWAITX-based delay:           252738 uWatts average power
      
      Thus, that's about 240 milliWatts less power consumption. The
      test method relies on the support of AMD CPU accumulated power
      algorithm in fam15h_power for which patches are forthcoming.
      Suggested-by: NAndy Lutomirski <luto@amacapital.net>
      Suggested-by: NBorislav Petkov <bp@suse.de>
      Suggested-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NHuang Rui <ray.huang@amd.com>
      [ Fix delay truncation. ]
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Aaron Lu <aaron.lu@intel.com>
      Cc: Andreas Herrmann <herrmann.der.user@gmail.com>
      Cc: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hector Marco-Gisbert <hecmargi@upv.es>
      Cc: Jacob Shin <jacob.w.shin@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Li <tony.li@amd.com>
      Link: http://lkml.kernel.org/r/1438744732-1459-3-git-send-email-ray.huang@amd.com
      Link: http://lkml.kernel.org/r/1439201994-28067-4-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b466bdb6
  6. 06 7月, 2015 4 次提交
  7. 07 1月, 2014 1 次提交
  8. 04 1月, 2013 1 次提交
    • G
      X86: drivers: remove __dev* attributes. · a18e3690
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, __devinitconst,
      and __devexit from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      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: Daniel Drake <dsd@laptop.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a18e3690
  9. 10 3月, 2012 1 次提交
    • T
      x86: Derandom delay_tsc for 64 bit · a7f4255f
      Thomas Gleixner 提交于
      Commit f0fbf0ab ("x86: integrate delay functions") converted
      delay_tsc() into a random delay generator for 64 bit.  The reason is
      that it merged the mostly identical versions of delay_32.c and
      delay_64.c.  Though the subtle difference of the result was:
      
       static void delay_tsc(unsigned long loops)
       {
      -	unsigned bclock, now;
      +	unsigned long bclock, now;
      
      Now the function uses rdtscl() which returns the lower 32bit of the
      TSC. On 32bit that's not problematic as unsigned long is 32bit. On 64
      bit this fails when the lower 32bit are close to wrap around when
      bclock is read, because the following check
      
             if ((now - bclock) >= loops)
             	  	break;
      
      evaluated to true on 64bit for e.g. bclock = 0xffffffff and now = 0
      because the unsigned long (now - bclock) of these values results in
      0xffffffff00000001 which is definitely larger than the loops
      value. That explains Tvortkos observation:
      
      "Because I am seeing udelay(500) (_occasionally_) being short, and
       that by delaying for some duration between 0us (yep) and 491us."
      
      Make those variables explicitely u32 again, so this works for both 32
      and 64 bit.
      Reported-by: NTvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org # >= 2.6.27
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a7f4255f
  10. 04 1月, 2011 1 次提交
  11. 26 6月, 2009 1 次提交
    • P
      x86, delay: tsc based udelay should have rdtsc_barrier · e888d7fa
      Pallipadi, Venkatesh 提交于
      delay_tsc needs rdtsc_barrier to provide proper delay.
      
      Output from a test driver using hpet to cross check delay
      provided by udelay().
      
      Before:
      [   86.794363] Expected delay 5us actual 4679ns
      [   87.154362] Expected delay 5us actual 698ns
      [   87.514162] Expected delay 5us actual 4539ns
      [   88.653716] Expected delay 5us actual 4539ns
      [   94.664106] Expected delay 10us actual 9638ns
      [   95.049351] Expected delay 10us actual 10126ns
      [   95.416110] Expected delay 10us actual 9568ns
      [   95.799216] Expected delay 10us actual 9638ns
      [  103.624104] Expected delay 10us actual 9707ns
      [  104.020619] Expected delay 10us actual 768ns
      [  104.419951] Expected delay 10us actual 9707ns
      
      After:
      [   50.983320] Expected delay 5us actual 5587ns
      [   51.261807] Expected delay 5us actual 5587ns
      [   51.565715] Expected delay 5us actual 5657ns
      [   51.861171] Expected delay 5us actual 5587ns
      [   52.164704] Expected delay 5us actual 5726ns
      [   52.487457] Expected delay 5us actual 5657ns
      [   52.789338] Expected delay 5us actual 5726ns
      [   57.119680] Expected delay 10us actual 10755ns
      [   57.893997] Expected delay 10us actual 10615ns
      [   58.261287] Expected delay 10us actual 10755ns
      [   58.620505] Expected delay 10us actual 10825ns
      [   58.941035] Expected delay 10us actual 10755ns
      [   59.320903] Expected delay 10us actual 10615ns
      [   61.306311] Expected delay 10us actual 10755ns
      [   61.520542] Expected delay 10us actual 10615ns
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      e888d7fa
  12. 09 7月, 2008 4 次提交
  13. 17 6月, 2008 1 次提交
    • J
      x86: fix bug in arch/i386/lib/delay.c file, delay_loop function · e01b70ef
      Jiri Hladky 提交于
      when trying to understand how Bogomips are implemented I have found a
      bug in arch/i386/lib/delay.c file, delay_loop function.
      
      The function fails for loops > 2^31+1. It because SF is set when dec
      returns numbers > 2^31.
      
      The fix is to use jnz instruction instead of jns (and add one decl
      instruction to the end to have exactly the same number of loops as in
      original version).
      
      Martin Mares observed:
      
      > It is a long time since I have hacked that file, but you should definitely
      > make sure that the function is never called with a zero argument. In such
      > case, the original version made just a single pass, but your version
      > makes 2^32 of them.
      
      fixed that.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e01b70ef
  14. 04 6月, 2008 1 次提交
    • S
      x86: enable preemption in delay · 5c1ea082
      Steven Rostedt 提交于
      The RT team has been searching for a nasty latency. This latency shows
      up out of the blue and has been seen to be as big as 5ms!
      
      Using ftrace I found the cause of the latency.
      
         pcscd-2995  3dNh1 52360300us : irq_exit (smp_apic_timer_interrupt)
         pcscd-2995  3dN.2 52360301us : idle_cpu (irq_exit)
         pcscd-2995  3dN.2 52360301us : rcu_irq_exit (irq_exit)
         pcscd-2995  3dN.1 52360771us : smp_apic_timer_interrupt (apic_timer_interrupt
      )
         pcscd-2995  3dN.1 52360771us : exit_idle (smp_apic_timer_interrupt)
      
      Here's an example of a 400 us latency. pcscd took a timer interrupt and
      returned with "need resched" enabled, but did not reschedule until after
      the next interrupt came in at 52360771us 400us later!
      
      At first I thought we somehow missed a preemption check in entry.S. But
      I also noticed that this always seemed to happen during a __delay call.
      
         pcscd-2995  3dN.2 52360836us : rcu_irq_exit (irq_exit)
         pcscd-2995  3.N.. 52361265us : preempt_schedule (__delay)
      
      Looking at the x86 delay, I found my problem.
      
      In git commit 35d5d08a, Andrew Morton
      placed preempt_disable around the entire delay due to TSC's not working
      nicely on SMP.  Unfortunately for those that care about latencies this
      is devastating! Especially when we have callers to mdelay(8).
      
      Here I enable preemption during the loop and account for anytime the task
      migrates to a new CPU. The delay asked for may be extended a bit by
      the migration, but delay only guarantees that it will delay for that minimum
      time. Delaying longer should not be an issue.
      
      [
        Thanks to Thomas Gleixner for spotting that cpu wasn't updated,
          and to place the rep_nop between preempt_enabled/disable.
      ]
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Cc: akpm@osdl.org
      Cc: Clark Williams <clark.williams@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: "Luis Claudio R. Goncalves" <lclaudio@uudg.org>
      Cc: Gregory Haskins <ghaskins@novell.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andi Kleen <andi-suse@firstfloor.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      5c1ea082
  15. 07 2月, 2008 1 次提交
    • A
      read_current_timer() cleanups · 941e492b
      Andrew Morton 提交于
      - All implementations can be __devinit
      
      - The function prototypes were in asm/timex.h but they all must be the same,
        so create a single declaration in linux/timex.h.
      
      - uninline the sparc64 version to match the other architectures
      
      - Don't bother #defining ARCH_HAS_READ_CURRENT_TIMER to a particular value.
      
      [ezk@cs.sunysb.edu: fix build]
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      941e492b
  16. 15 11月, 2007 1 次提交
  17. 20 10月, 2007 1 次提交
    • M
      x86: convert cpuinfo_x86 array to a per_cpu array · 92cb7612
      Mike Travis 提交于
      cpu_data is currently an array defined using NR_CPUS.  This means that
      we overallocate since we will rarely really use maximum configured cpus.
      When NR_CPU count is raised to 4096 the size of cpu_data becomes
      3,145,728 bytes.
      
      These changes were adopted from the sparc64 (and ia64) code.  An
      additional field was added to cpuinfo_x86 to be a non-ambiguous cpu
      index.  This corresponds to the index into a cpumask_t as well as the
      per_cpu index.  It's used in various places like show_cpuinfo().
      
      cpu_data is defined to be the boot_cpu_data structure for the NON-SMP
      case.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Acked-by: NChristoph Lameter <clameter@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Cc: Mark M. Hoffman <mhoffman@lightlink.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      92cb7612
  18. 11 10月, 2007 2 次提交
  19. 01 10月, 2006 1 次提交
  20. 27 6月, 2006 1 次提交
  21. 24 6月, 2005 1 次提交
  22. 22 6月, 2005 1 次提交
    • I
      [PATCH] smp_processor_id() cleanup · 39c715b7
      Ingo Molnar 提交于
      This patch implements a number of smp_processor_id() cleanup ideas that
      Arjan van de Ven and I came up with.
      
      The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
      spaghetti was hard to follow both on the implementational and on the
      usage side.
      
      Some of the complexity arose from picking wrong names, some of the
      complexity comes from the fact that not all architectures defined
      __smp_processor_id.
      
      In the new code, there are two externally visible symbols:
      
       - smp_processor_id(): debug variant.
      
       - raw_smp_processor_id(): nondebug variant. Replaces all existing
         uses of _smp_processor_id() and __smp_processor_id(). Defined
         by every SMP architecture in include/asm-*/smp.h.
      
      There is one new internal symbol, dependent on DEBUG_PREEMPT:
      
       - debug_smp_processor_id(): internal debug variant, mapped to
                                   smp_processor_id().
      
      Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
      lib/smp_processor_id.c file.  All related comments got updated and/or
      clarified.
      
      I have build/boot tested the following 8 .config combinations on x86:
      
       {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
      
      I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT.  (Other
      architectures are untested, but should work just fine.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39c715b7
  23. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4