1. 20 3月, 2006 3 次提交
    • D
      [SPARC64]: Dynamically grow TSB in response to RSS growth. · bd40791e
      David S. Miller 提交于
      As the RSS grows, grow the TSB in order to reduce the likelyhood
      of hash collisions and thus poor hit rates in the TSB.
      
      This definitely needs some serious tuning.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd40791e
    • D
      [SPARC64]: Elminate all usage of hard-coded trap globals. · 56fb4df6
      David S. Miller 提交于
      UltraSPARC has special sets of global registers which are switched to
      for certain trap types.  There is one set for MMU related traps, one
      set of Interrupt Vector processing, and another set (called the
      Alternate globals) for all other trap types.
      
      For what seems like forever we've hard coded the values in some of
      these trap registers.  Some examples include:
      
      1) Interrupt Vector global %g6 holds current processors interrupt
         work struct where received interrupts are managed for IRQ handler
         dispatch.
      
      2) MMU global %g7 holds the base of the page tables of the currently
         active address space.
      
      3) Alternate global %g6 held the current_thread_info() value.
      
      Such hardcoding has resulted in some serious issues in many areas.
      There are some code sequences where having another register available
      would help clean up the implementation.  Taking traps such as
      cross-calls from the OBP firmware requires some trick code sequences
      wherein we have to save away and restore all of the special sets of
      global registers when we enter/exit OBP.
      
      We were also using the IMMU TSB register on SMP to hold the per-cpu
      area base address, which doesn't work any longer now that we actually
      use the TSB facility of the cpu.
      
      The implementation is pretty straight forward.  One tricky bit is
      getting the current processor ID as that is different on different cpu
      variants.  We use a stub with a fancy calling convention which we
      patch at boot time.  The calling convention is that the stub is
      branched to and the (PC - 4) to return to is in register %g1.  The cpu
      number is left in %g6.  This stub can be invoked by using the
      __GET_CPUID macro.
      
      We use an array of per-cpu trap state to store the current thread and
      physical address of the current address space's page tables.  The
      TRAP_LOAD_THREAD_REG loads %g6 with the current thread from this
      table, it uses __GET_CPUID and also clobbers %g1.
      
      TRAP_LOAD_IRQ_WORK is used by the interrupt vector processing to load
      the current processor's IRQ software state into %g6.  It also uses
      __GET_CPUID and clobbers %g1.
      
      Finally, TRAP_LOAD_PGD_PHYS loads the physical address base of the
      current address space's page tables into %g7, it clobbers %g1 and uses
      __GET_CPUID.
      
      Many refinements are possible, as well as some tuning, with this stuff
      in place.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56fb4df6
    • D
      [SPARC64]: Move away from virtual page tables, part 1. · 74bf4312
      David S. Miller 提交于
      We now use the TSB hardware assist features of the UltraSPARC
      MMUs.
      
      SMP is currently knowingly broken, we need to find another place
      to store the per-cpu base pointers.  We hid them away in the TSB
      base register, and that obviously will not work any more :-)
      
      Another known broken case is non-8KB base page size.
      
      Also noticed that flush_tlb_all() is not referenced anywhere, only
      the internal __flush_tlb_all() (local cpu only) is used by the
      sparc64 port, so we can get rid of flush_tlb_all().
      
      The kernel gets it's own 8KB TSB (swapper_tsb) and each address space
      gets it's own private 8K TSB.  Later we can add code to dynamically
      increase the size of per-process TSB as the RSS grows.  An 8KB TSB is
      good enough for up to about a 4MB RSS, after which the TSB starts to
      incur many capacity and conflict misses.
      
      We even accumulate OBP translations into the kernel TSB.
      
      Another area for refinement is large page size support.  We could use
      a secondary address space TSB to handle those.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74bf4312
  2. 27 2月, 2006 1 次提交
  3. 13 1月, 2006 1 次提交
  4. 12 11月, 2005 1 次提交
  5. 09 11月, 2005 2 次提交
    • N
      [PATCH] sched: resched and cpu_idle rework · 64c7c8f8
      Nick Piggin 提交于
      Make some changes to the NEED_RESCHED and POLLING_NRFLAG to reduce
      confusion, and make their semantics rigid.  Improves efficiency of
      resched_task and some cpu_idle routines.
      
      * In resched_task:
      - TIF_NEED_RESCHED is only cleared with the task's runqueue lock held,
        and as we hold it during resched_task, then there is no need for an
        atomic test and set there. The only other time this should be set is
        when the task's quantum expires, in the timer interrupt - this is
        protected against because the rq lock is irq-safe.
      
      - If TIF_NEED_RESCHED is set, then we don't need to do anything. It
        won't get unset until the task get's schedule()d off.
      
      - If we are running on the same CPU as the task we resched, then set
        TIF_NEED_RESCHED and no further action is required.
      
      - If we are running on another CPU, and TIF_POLLING_NRFLAG is *not* set
        after TIF_NEED_RESCHED has been set, then we need to send an IPI.
      
      Using these rules, we are able to remove the test and set operation in
      resched_task, and make clear the previously vague semantics of
      POLLING_NRFLAG.
      
      * In idle routines:
      - Enter cpu_idle with preempt disabled. When the need_resched() condition
        becomes true, explicitly call schedule(). This makes things a bit clearer
        (IMO), but haven't updated all architectures yet.
      
      - Many do a test and clear of TIF_NEED_RESCHED for some reason. According
        to the resched_task rules, this isn't needed (and actually breaks the
        assumption that TIF_NEED_RESCHED is only cleared with the runqueue lock
        held). So remove that. Generally one less locked memory op when switching
        to the idle thread.
      
      - Many idle routines clear TIF_POLLING_NRFLAG, and only set it in the inner
        most polling idle loops. The above resched_task semantics allow it to be
        set until before the last time need_resched() is checked before going into
        a halt requiring interrupt wakeup.
      
        Many idle routines simply never enter such a halt, and so POLLING_NRFLAG
        can be always left set, completely eliminating resched IPIs when rescheduling
        the idle task.
      
        POLLING_NRFLAG width can be increased, to reduce the chance of resched IPIs.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Con Kolivas <kernel@kolivas.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      64c7c8f8
    • N
      [PATCH] sched: disable preempt in idle tasks · 5bfb5d69
      Nick Piggin 提交于
      Run idle threads with preempt disabled.
      
      Also corrected a bugs in arm26's cpu_idle (make it actually call schedule()).
      How did it ever work before?
      
      Might fix the CPU hotplugging hang which Nigel Cunningham noted.
      
      We think the bug hits if the idle thread is preempted after checking
      need_resched() and before going to sleep, then the CPU offlined.
      
      After calling stop_machine_run, the CPU eventually returns from preemption and
      into the idle thread and goes to sleep.  The CPU will continue executing
      previous idle and have no chance to call play_dead.
      
      By disabling preemption until we are ready to explicitly schedule, this bug is
      fixed and the idle threads generally become more robust.
      
      From: alexs <ashepard@u.washington.edu>
      
        PPC build fix
      
      From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
      
        MIPS build fix
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NYoichi Yuasa <yuasa@hh.iij4u.or.jp>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5bfb5d69
  6. 08 11月, 2005 2 次提交
    • D
      [SPARC64] mm: Do not flush TLB mm in tlb_finish_mmu() · 62dbec78
      David S. Miller 提交于
      It isn't needed any longer, as noted by Hugh Dickins.
      
      We still need the flush routines, due to the one remaining
      call site in hugetlb_prefault_arch_hook().  That can be
      eliminated at some later point, however.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62dbec78
    • H
      [SPARC64] mm: context switch ptlock · dedeb002
      Hugh Dickins 提交于
      sparc64 is unique among architectures in taking the page_table_lock in
      its context switch (well, cris does too, but erroneously, and it's not
      yet SMP anyway).
      
      This seems to be a private affair between switch_mm and activate_mm,
      using page_table_lock as a per-mm lock, without any relation to its uses
      elsewhere.  That's fine, but comment it as such; and unlock sooner in
      switch_mm, more like in activate_mm (preemption is disabled here).
      
      There is a block of "if (0)"ed code in smp_flush_tlb_pending which would
      have liked to rely on the page_table_lock, in switch_mm and elsewhere;
      but its comment explains how dup_mmap's flush_tlb_mm defeated it.  And
      though that could have been changed at any time over the past few years,
      now the chance vanishes as we push the page_table_lock downwards, and
      perhaps split it per page table page.  Just delete that block of code.
      
      Which leaves the mysterious spin_unlock_wait(&oldmm->page_table_lock)
      in kernel/fork.c copy_mm.  Textual analysis (supported by Nick Piggin)
      suggests that the comment was written by DaveM, and that it relates to
      the defeated approach in the sparc64 smp_flush_tlb_pending.  Just delete
      this block too.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dedeb002
  7. 15 10月, 2005 1 次提交
    • D
      [SPARC64]: Fix powering off on SMP. · b4d1b825
      David S. Miller 提交于
      Doing a "SUNW,stop-self" firmware call on the other cpus is not the
      correct thing to do when dropping into the firmware for a halt,
      reboot, or power-off.
      
      For now, just do nothing to quiet the other cpus, as the system should
      be quiescent enough.  Later we may decide to implement smp_send_stop()
      like the other SMP platforms do.
      
      Based upon a report from Christopher Zimmermann.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4d1b825
  8. 26 9月, 2005 1 次提交
    • D
      [SPARC64]: Probe D/I/E-cache config and use. · 80dc0d6b
      David S. Miller 提交于
      At boot time, determine the D-cache, I-cache and E-cache size and
      line-size.  Use them in cache flushes when appropriate.
      
      This change was motivated by discovering that the D-cache on
      UltraSparc-IIIi and later are 64K not 32K, and the flushes done by the
      Cheetah error handlers were assuming a 32K size.
      
      There are still some pieces of code that are hard coding things and
      will need to be fixed up at some point.
      
      While we're here, fix the D-cache and I-cache parity error handlers
      to run with interrupts disabled, and when the trap occurs at trap
      level > 1 log the event via a counter displayed in /proc/cpuinfo.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80dc0d6b
  9. 30 8月, 2005 1 次提交
  10. 25 7月, 2005 1 次提交
  11. 13 7月, 2005 1 次提交
  12. 11 7月, 2005 1 次提交
  13. 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
  14. 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