>thrash/deadlock/crash.  I don't think you want to return to the old 4.3
>strategy of pre-allocating swap, this is overly restrictive.

Yet, as the FreeBSD folks have pointed out, it can make things much
less hectic in a severe memory crunch.  If clean pages are already in
swap when it comes time to grab a whole bunch of memory, they don't
have to be written out in a mad rush for memory.  And, disk is *much*
cheaper than RAM.  If aggresive pre-allocation was a big win,
performance-wise, in low memory situations, I don't mind throwing a
hundred bucks at another used drive and picking up a couple hundred
meg of swap.

>3. Page in/out done page at a time.
>
>This is clustering of pageouts and pre-paging for pagein.  4K or 8K is seldom
>the optimal IO size for most modern disks :-)  Late in the game I made the
>pager interface support multiple pages and did a quicky hack to the pageout
>daemon to do clustered pageout.  Clustered pageout helped some, but pagein is
>more important (and harder policy-wise).
>
>4. No bulk pageout (i.e., ``swapping'')
>
>Arguably, this is not necessary but in practice it seems to help a lot
>under extreme memory pressure.  Swapping is really just a more aggressive
>form of clustered pageout.

My experience (working with a memory-starved Ultrix machine) has shown
me that, although it's sometimes annoying to have a process you want
sitting completely on a swap drive, overall, it can ease the memory
burden on the machine much quicker when a sudden need for memory
arises.  Maybe it's just masking the problem (i. e. you need more
RAM), but it seemed to be a positive feature.

>1. It has severe portability problems.  I have no strong reason to believe
>   this is the case, though, for example, I have heard of an optimization
>   that pre-loads page table entries-- not very meaningful to me and my
>   small, software-loaded TLB.  As long as these things are below the MI/MD
>   line that is ok.  Anyway, hopefully we can avoid going back to portability
>   meaning "make it look like a VAX" (though this seems to be the Linux
>   approach (s/VAX/x86/)).

Chris has stated several times in detail some of the places the
FreeBSD system falls short.  I would love to see all of Chris' ideas
implemented.  But, will they ever really get implemented, and when?

Is it better to keep saying "no, that way is wrong, and we will only
take something `correct'", or to take a less than optimal design now,
which is better than what we have, and continue to dream about the One
True Solution?  This is a rhetorical question...

>2. You aspire to do something other than make the existing mmap interface
>   better (fast, efficient, robust, etc.).  If what your users want is a
>   fast BSD-as-we-know-it system then why waste your time re-inventing the
>   wheel?  Take advantage of the FreeBSD work and spend time on other things
>   like MP support.  However, if you are going to dip your wick in the
>   VM buzzword pool (e.g., distributed shared memory, page coloring,
>   multiple page sizes, remote memory paging, application controlled paging
>   policy/mechanism, separate physical memory pools, persistent virtual
>   memory, protection domains, single address space, shared address spaces, 
>   andonandonandon) then FreeBSD is probably not the place to start.  I
>   don't know what the goals for NetBSD are in this regard.

Once again, this is all quite cool.  But, should we leave the current
sub-optimal design in favor of some really cool stuff that may never
get fully implemented.  With respect to redesigning the VM system, I'm
all in favor of Doing It Right The First Time, but that's assuming
there will be a first time.  It might be a good idea to focus on just
what we realistically think can be accomplished in the next year or
two, given the limited development resources, and other tasks that
also require them.

With all this said, I think at least planning a redesign of the VM
system should be a very high priority.

Just some thoughts...  Not trying to step on anyone's toes...

-----------------------------------------------------------------------------
  Michael L. VanLoon                                 michaelv@HeadCandy.com
       --<  Free your mind and your machine -- NetBSD free un*x  >--
     NetBSD working ports: 386+PC, Mac 68k, Amiga, HP300, Sun3, Sun4,
                           DEC PMAX (MIPS), DEC Alpha, PC532
     NetBSD ports in progress: VAX, Atari 68k, others...
-----------------------------------------------------------------------------