1. 21 3月, 2006 33 次提交
  2. 20 3月, 2006 7 次提交
    • D
      [SPARC64]: Fix 2 bugs in huge page support. · f6b83f07
      David S. Miller 提交于
      1) huge_pte_offset() did not check the page table hierarchy
         elements as being empty correctly, resulting in an OOPS
      
      2) Need platform specific hugetlb_get_unmapped_area() to handle
         the top-down vs. bottom-up address space allocation strategies.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6b83f07
    • D
      [SPARC64]: Optimized TSB table initialization. · bb8646d8
      David S. Miller 提交于
      We only need to write an invalid tag every 16 bytes,
      so taking advantage of this can save many instructions
      compared to the simple memset() call we make now.
      
      A prefetching implementation is implemented for sun4u
      and a block-init store version if implemented for Niagara.
      
      The next trick is to be able to perform an init and
      a copy_tsb() in parallel when growing a TSB table.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb8646d8
    • D
      [SPARC64]: Increase top of 32-bit process stack. · d61e16df
      David S. Miller 提交于
      Put it one page below the top of the 32-bit address space.
      This gives us ~16MB more address space to work with.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d61e16df
    • D
      [SPARC64]: Top-down address space allocation for 32-bit tasks. · a91690dd
      David S. Miller 提交于
      Currently allocations are very constrained for 32-bit processes.
      It grows down-up from 0x70000000 to 0xf0000000 which gives about
      2GB of stack + dynamic mmap() space.
      
      So support the top-down method, and we need to override the
      generic helper function in order to deal with D-cache coloring.
      
      With these changes I was able to squeeze out a mmap() just over
      3.6GB in size in a 32-bit process.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a91690dd
    • D
      [SPARC64]: Fix and re-enable dynamic TSB sizing. · 7a1ac526
      David S. Miller 提交于
      This is good for up to %50 performance improvement of some test cases.
      The problem has been the race conditions, and hopefully I've plugged
      them all up here.
      
      1) There was a serious race in switch_mm() wrt. lazy TLB
         switching to and from kernel threads.
      
         We could erroneously skip a tsb_context_switch() and thus
         use a stale TSB across a TSB grow event.
      
         There is a big comment now in that function describing
         exactly how it can happen.
      
      2) All code paths that do something with the TSB need to be
         guarded with the mm->context.lock spinlock.  This makes
         page table flushing paths properly synchronize with both
         TSB growing and TLB context changes.
      
      3) TSB growing events are moved to the end of successful fault
         processing.  Previously it was in update_mmu_cache() but
         that is deadlock prone.  At the end of do_sparc64_fault()
         we hold no spinlocks that could deadlock the TSB grow
         sequence.  We also have dropped the address space semaphore.
      
      While we're here, add prefetching to the copy_tsb() routine
      and put it in assembler into the tsb.S file.  This piece of
      code is quite time critical.
      
      There are some small negative side effects to this code which
      can be improved upon.  In particular we grab the mm->context.lock
      even for the tsb insert done by update_mmu_cache() now and that's
      a bit excessive.  We can get rid of that locking, and the same
      lock taking in flush_tsb_user(), by disabling PSTATE_IE around
      the whole operation including the capturing of the tsb pointer
      and tsb_nentries value.  That would work because anyone growing
      the TSB won't free up the old TSB until all cpus respond to the
      TSB change cross call.
      
      I'm not quite so confident in that optimization to put it in
      right now, but eventually we might be able to and the description
      is here for reference.
      
      This code seems very solid now.  It passes several parallel GCC
      bootstrap builds, and our favorite "nut cruncher" stress test which is
      a full "make -j8192" build of a "make allmodconfig" kernel.  That puts
      about 256 processes on each cpu's run queue, makes lots of process cpu
      migrations occur, causes lots of page table and TLB flushing activity,
      incurs many context version number changes, and it swaps the machine
      real far out to disk even though there is 16GB of ram on this test
      system. :-)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7a1ac526
    • D
      [SPARC64]: Fix system type in /proc/cpuinfo and remove bogus OBP check. · 90a6646b
      David S. Miller 提交于
      Report 'sun4v' when appropriate in /proc/cpuinfo
      
      Remove all the verifications of the OBP version string.  Just
      make sure it's there, and report it raw in the bootup logs and
      via /proc/cpuinfo.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      90a6646b
    • D
      [SPARC64]: Add SMT scheduling support for Niagara. · 8935dced
      David S. Miller 提交于
      The mapping is a simple "(cpuid >> 2) == core" for now.
      Later we'll add more sophisticated code that will walk
      the sun4v machine description and figure this out from
      there.
      
      We should also add core mappings for jaguar and panther
      processors.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8935dced