lkml.org 
[lkml]   [1999]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: bad lmbench numbers for mmap
   Date: Sat, 17 Apr 1999 03:21:45 +0200
From: Jamie Lokier <lkd@tantalophile.demon.co.uk>

David Miller wrote:
> Yes do have to clear them, for two reasons:
>
> 1) So that the hardware MMU doesn't see valid entries after the
> tlb flush. (or in the case of clever software TLB miss strategies
> like that implemeted in the Alpha PAL code or in our sparc64 port,
> making sure the virtual page table mappings go away properly too)

In the hardware case, this isn't true (correct me) if you flush the TLB
after clearing the page directory entries, surely?

We do, and do it right on x86 etc. but that scheme really doesn't
work for the clever Alpha/sparc64 methods in all cases. I discussed
with Linus adding a "flush_tlb_pgtables(mm, begin, end)" method or
similar to deal with this.

I think Alpha might get lucky in this case because it does a full mm
flush for tlb range flushes (which will happen right before
flush_pgtables is called), whereas on sparc64 we do a more finegrained
tlb flush for ranges which won't take care of the virtual page table
mappings used by the TLB miss scheme.

Point taken. #2 means nothing would be gained. (Unless clearing a
whole page is faster than clearing one pte at a time..)

Clearing a whole page is faster on UltraSparc, because it would use
the high speed VIS block memory stores which avoid cache pollution.
Similar tricks could be done on the modern Pentiums...

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.177 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site