lkml.org 
[lkml]   [2007]   [Jul]   [4]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [patch 1/5] avoid tlb gather restarts.
    FromMartin Schwidefsky <>
    DateWed, 04 Jul 2007 09:37:51 +0200
    On Tue, 2007-07-03 at 18:42 +0100, Hugh Dickins wrote:
    > > If need_resched() is false in the inner loop of unmap_vmas it is
    > > unnecessary to do a full blown tlb_finish_mmu / tlb_gather_mmu for
    > > each ZAP_BLOCK_SIZE ptes. Do a tlb_flush_mmu() instead. That gives
    > > architectures with a non-generic tlb flush implementation room for
    > > optimization. The tlb_flush_mmu primitive is a available with the
    > > generic tlb flush code, the ia64_tlb_flush_mm needs to be renamed
    > > and a dummy function is added to arm and arm26.
    > > 
    > > Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    > 
    > Acked-by: Hugh Dickins <hugh@veritas.com>
    > 
    > (Looking at it, I see that we could argue that there ought to be a
    > need_resched() etc. check after your tlb_flush_mmu() in unmap_vmas,
    > in case it's spent a long while in there on some arches; but I don't
    > think we have the ZAP_BLOCK_SIZE tuned with any great precision, and
    > you'd at worst be doubling the latency there, so let's not worry
    > about it.  I write this merely in order to reserve myself an
    > "I told you so" if anyone ever notices increased latency ;)
    
    Hmm, we'd have to repeat the longish if statement to make sure we don't
    miss a cond_resched after tlb_flush_mmu. I'd rather not do that.
    
    -- 
    blue skies,
      Martin.
    
    "Reality continues to ruin my life." - Calvin.
    
    
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2007-07-04 09:39    [from the cache]
    ©2003-2008