1. 28 6月, 2005 1 次提交
    • D
      [SPARC64]: Avoid membar instructions in delay slots. · b445e26c
      David S. Miller 提交于
      In particular, avoid membar instructions in the delay
      slot of a jmpl instruction.
      
      UltraSPARC-I, II, IIi, and IIe have a bug, documented in
      the UltraSPARC-IIi User's Manual, Appendix K, Erratum 51
      
      The long and short of it is that if the IMU unit misses
      on a branch or jmpl, and there is a store buffer synchronizing
      membar in the delay slot, the chip can stop fetching instructions.
      
      If interrupts are enabled or some other trap is enabled, the
      chip will unwedge itself, but performance will suffer.
      
      We already had a workaround for this bug in a few spots, but
      it's better to have the entire tree sanitized for this rule.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b445e26c
  2. 26 6月, 2005 2 次提交
    • N
      [PATCH] sched: cleanup context switch locking · 4866cde0
      Nick Piggin 提交于
      Instead of requiring architecture code to interact with the scheduler's
      locking implementation, provide a couple of defines that can be used by the
      architecture to request runqueue unlocked context switches, and ask for
      interrupts to be enabled over the context switch.
      
      Also replaces the "switch_lock" used by these architectures with an oncpu
      flag (note, not a potentially slow bitflag).  This eliminates one bus
      locked memory operation when context switching, and simplifies the
      task_running function.
      Signed-off-by: NNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4866cde0
    • P
      [PATCH] RCU: clean up a few remaining synchronize_kernel() calls · b2b18660
      Paul E. McKenney 提交于
      2.6.12-rc6-mm1 has a few remaining synchronize_kernel()s, some (but not
      all) in comments.  This patch changes these synchronize_kernel() calls (and
      comments) to synchronize_rcu() or synchronize_sched() as follows:
      
      - arch/x86_64/kernel/mce.c mce_read(): change to synchronize_sched() to
        handle races with machine-check exceptions (synchronize_rcu() would not cut
        it given RCU implementations intended for hardcore realtime use.
      
      - drivers/input/serio/i8042.c i8042_stop(): change to synchronize_sched() to
        handle races with i8042_interrupt() interrupt handler.  Again,
        synchronize_rcu() would not cut it given RCU implementations intended for
        hardcore realtime use.
      
      - include/*/kdebug.h comments: change to synchronize_sched() to handle races
        with NMIs.  As before, synchronize_rcu() would not cut it...
      
      - include/linux/list.h comment: change to synchronize_rcu(), since this
        comment is for list_del_rcu().
      
      - security/keys/key.c unregister_key_type(): change to synchronize_rcu(),
        since this is interacting with RCU read side.
      
      - security/keys/process_keys.c install_session_keyring(): change to
        synchronize_rcu(), since this is interacting with RCU read side.
      Signed-off-by: N"Paul E. McKenney" <paulmck@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b2b18660
  3. 25 6月, 2005 1 次提交
  4. 24 6月, 2005 2 次提交
  5. 22 6月, 2005 3 次提交
    • D
      [PATCH] Hugepage consolidation · 63551ae0
      David Gibson 提交于
      A lot of the code in arch/*/mm/hugetlbpage.c is quite similar.  This patch
      attempts to consolidate a lot of the code across the arch's, putting the
      combined version in mm/hugetlb.c.  There are a couple of uglyish hacks in
      order to covert all the hugepage archs, but the result is a very large
      reduction in the total amount of code.  It also means things like hugepage
      lazy allocation could be implemented in one place, instead of six.
      
      Tested, at least a little, on ppc64, i386 and x86_64.
      
      Notes:
      	- this patch changes the meaning of set_huge_pte() to be more
      	  analagous to set_pte()
      	- does SH4 need s special huge_ptep_get_and_clear()??
      Acked-by: NWilliam Lee Irwin <wli@holomorphy.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      63551ae0
    • 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
    • D
      [SPARC64]: Add prefetch support. · 7049e680
      David S. Miller 提交于
      The implementation is optimal for UltraSPARC-III and later.
      It will work, however suboptimally, on UltraSPARC-II and
      be treated as a NOP on UltraSPARC-I.
      
      It is not worth code patching this thing as the highest cost
      is the code space, and code patching cannot eliminate that.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7049e680
  6. 08 6月, 2005 1 次提交
    • K
      [PATCH] AGP fix for Xen VMM · 07eee78e
      Keir Fraser 提交于
      When Linux is running on the Xen virtual machine monitor, physical
      addresses are virtualised and cannot be directly referenced by the AGP
      GART.  This patch fixes the GART driver for Xen by adding a layer of
      abstraction between physical addresses and 'GART addresses'.
      
      Architecture-specific functions are also defined for allocating and freeing
      the GATT.  Xen requires this to ensure that table really is contiguous from
      the point of view of the GART.
      
      These extra interface functions are defined as 'no-ops' for all existing
      architectures that use the GART driver.
      Signed-off-by: NKeir Fraser <keir@xensource.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDave Jones <davej@redhat.com>
      07eee78e
  7. 01 6月, 2005 1 次提交
  8. 24 5月, 2005 1 次提交
    • D
      [SPARC64]: Add boot option to force UltraSPARC-III P-Cache on. · 816242da
      David S. Miller 提交于
      Older UltraSPARC-III chips have a P-Cache bug that makes us disable it
      by default at boot time.
      
      However, this does hurt performance substantially, particularly with
      memcpy(), and the bug is _incredibly_ obscure.  I have never seen it
      triggered in practice, ever.
      
      So provide a "-P" boot option that forces the P-Cache on.  It taints
      the kernel, so if it does trigger and cause some data corruption or
      OOPS, we will find out in the logs that this option was on when it
      happened.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      816242da
  9. 06 5月, 2005 1 次提交
  10. 04 5月, 2005 2 次提交
  11. 01 5月, 2005 4 次提交
  12. 25 4月, 2005 2 次提交
  13. 22 4月, 2005 2 次提交
  14. 21 4月, 2005 1 次提交
  15. 20 4月, 2005 2 次提交
  16. 19 4月, 2005 1 次提交
  17. 18 4月, 2005 1 次提交
    • D
      [PATCH] sparc64: Reduce ptrace cache flushing · dadeafdf
      David S. Miller 提交于
      We were flushing the D-cache excessively for ptrace() processing
      and this makes debugging threads so slow as to be totally unusable.
      
      All process page accesses via ptrace() go via access_process_vm().
      This routine, for each process page, uses get_user_pages().  That
      in turn does a flush_dcache_page() on the child pages before we
      copy in/out the ptrace request data.
      
      Therefore, all we need to do after the data movement is:
      
      1) Flush the D-cache pages if the kernel maps the page to a different
         color than userspace does.
      2) If we wrote to the page, we need to flush the I-cache on older cpus.
      
      Previously we just flushed the entire cache at the end of a ptrace()
      request, and that was beyond stupid.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dadeafdf
  18. 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