• David S. Miller's avatar
    [SPARC64]: Fix and re-enable dynamic TSB sizing. · 7a1ac526
    David S. Miller authored
    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: default avatarDavid S. Miller <davem@davemloft.net>
    7a1ac526
tsb.S 8.3 KB