[src/trunk]: src/sys/arch/hp300/DOC File contents not interesting anymore, an...

[wiz <wiz%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/50413a1bc402
branches:  trunk
changeset: 518841:50413a1bc402
user:      wiz <wiz%NetBSD.org@localhost>
date:      Thu Dec 06 13:56:35 2001 +0000

description:
File contents not interesting anymore, and even partially wrong.
Remove it. Ok'd by chuq.

diffstat:

 sys/arch/hp300/DOC/Pmap.notes |  43 -------------------------------------------
 1 files changed, 0 insertions(+), 43 deletions(-)

diffs (47 lines):

diff -r f693c17fef12 -r 50413a1bc402 sys/arch/hp300/DOC/Pmap.notes
--- a/sys/arch/hp300/DOC/Pmap.notes     Thu Dec 06 13:18:22 2001 +0000
+++ /dev/null   Thu Jan 01 00:00:00 1970 +0000
@@ -1,43 +0,0 @@
-$NetBSD: Pmap.notes,v 1.3 2000/03/13 23:52:28 soren Exp $
-
-Following are some observations about the BSD hp300 pmap module that
-may prove useful for other pmap modules:
-
-1. pmap_remove should be efficient with large, sparsely populated ranges.
-
-   Profiling of exec/exit intensive work loads showed that much time was
-   being spent in pmap_remove.  This was primarily due to calls from exec
-   when deallocating the stack segment.  Since the current implementation
-   of the stack is to "lazy allocate" the maximum possible stack size
-   (typically 16-32mb) when the process is created, pmap_remove will be
-   called with a large chunk of largely empty address space.  It is
-   important that this routine be able to quickly skip over large chunks
-   of allocated but unpopulated VA space.  The hp300 pmap module did check
-   for unpopulated "segments" (which map 4mb chunks) and skipped them fairly
-   efficiently but once it found a valid segment descriptor (STE), it rather
-   clumsily moved forward over the PTEs mapping that segment.  Particularly
-   bad was that for every PTE it would recheck that the STE was valid even
-   though we should already know that.
-
-   pmap_protect can benefit from similar optimizations though it is
-   (currently) not called with large regions.
-
-   Another solution would be to change the way stack allocation is done
-   (i.e. don't preallocate the entire address range) but I think it is
-   important to be able to efficiently support such large, spare ranges
-   that might show up in other applications (e.g. a randomly accessed
-   large mapped file).
-
-2. Bit operations (i.e. ~,&,|) are more efficient than bitfields.
-
-   This is a 68k/gcc issue, but if you are trying to squeeze out maximum
-   performance...
-
-3. Don't flush TLB/caches for inactive mappings.
-
-   On the hp300 the TLBs are either designed as, or used in such a way that,
-   they are flushed on every context switch (i.e. there are no "process
-   tags")  Hence, doing TLB flushes on mappings that aren't associated with
-   either the kernel or the currently running process are a waste.  Seems
-   pretty obvious but I missed it for many years.  An analogous argument
-   applies to flushing untagged virtually addressed caches (ala the 320/350).