1. 09 7月, 2008 4 次提交
  2. 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
  3. 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
  4. 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
  5. 15 11月, 2007 1 次提交
  6. 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
  7. 11 10月, 2007 2 次提交
  8. 01 10月, 2006 1 次提交
  9. 27 6月, 2006 1 次提交
  10. 24 6月, 2005 1 次提交
  11. 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
  12. 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