i've just committed the top down changes to uvm that i've been working
on for...well...a while.  at this point, it's undergone rigorous
testing and survived everything i threw at it.

the effect this has on processes is most easily demontrated by looking
at a process's memory map.  previously, my shell looked like this:

    % pmap -lv
    08048000-0808b000 r-xp 00000000 00:05 4441659     /usr/pkg/bin/tcsh
    0808b000-0808f000 rw-p 00042000 00:05 4441659     /usr/pkg/bin/tcsh
    0808f000-080bb000 rw-p 00000000 00:00 0       [ anon ]
    080bb000-08113000 rwxp 00000000 00:00 0       [ heap ]
    08113000-081a1000 rwxp 00000000 00:00 0       [ anon ]
    [1]
    4808b000-48093000 r-xp 00000000 00:00 214177     /libexec/ld.elf_so
    48093000-4809c000 rw-p 00000000 00:00 0       [ anon ]
    4809c000-4809e000 r-xp 00000000 00:00 214167     /lib/libtermcap.so.0.5
    4809e000-480a0000 rw-p 00001000 00:00 214167     /lib/libtermcap.so.0.5
    480a0000-480a5000 r-xp 00000000 00:00 213871     /lib/libcrypt.so.0.1
    480a5000-480a7000 rw-p 00004000 00:00 213871     /lib/libcrypt.so.0.1
    480a7000-480aa000 rw-p 00000000 00:00 0       [ anon ]
    480aa000-48139000 r-xp 00000000 00:00 213851     /lib/libc.so.12.91
    48139000-4813f000 rw-p 0008e000 00:00 213851     /lib/libc.so.12.91
    4813f000-4814c000 rw-p 00000000 00:00 0       [ anon ]
    [2]
    bdc00000-bfa00000 ---p 00000000 00:00 0       [ stack ]
    bfa00000-bfbe0000 rwxp 00000000 00:00 0       [ stack ]
    bfbe0000-bfbf0000 rwxp 00000000 00:00 0       [ stack ]
    bfbf0000-bfc00000 rwxp 00000000 00:00 0       [ stack ]

where [1] is the area reserved for heap growth and [2] is the area
reserved for mmap()ed allocations.  now it looks like this:

    % pmap -lv
    08048000-0808b000 r-xp 00000000 00:04 2951414     /usr/pkg/bin/tcsh
    0808b000-0808f000 rw-p 00042000 00:04 2951414     /usr/pkg/bin/tcsh
    0808f000-080bb000 rw-p 00000000 00:00 0       [ anon ]
    080bb000-0810e000 rwxp 00000000 00:00 0       [ heap ]
    [3]
    bdb37000-bdbcb000 r-xp 00000000 00:00 39945     /lib/libc.so.12.94
    bdbcb000-bdbd1000 rw-p 00093000 00:00 39945     /lib/libc.so.12.94
    bdbd1000-bdbdf000 rw-p 00000000 00:00 0       [ anon ]
    bdbdf000-bdbe4000 r-xp 00000000 00:00 39943     /lib/libcrypt.so.0.1
    bdbe4000-bdbe6000 rw-p 00004000 00:00 39943     /lib/libcrypt.so.0.1
    bdbe6000-bdbe9000 rw-p 00000000 00:00 0       [ anon ]
    bdbe9000-bdbeb000 r-xp 00000000 00:00 39975     /lib/libtermcap.so.0.5
    bdbeb000-bdbed000 rw-p 00001000 00:00 39975     /lib/libtermcap.so.0.5
    bdbed000-bdbf5000 rw-p 00000000 00:00 0       [ anon ]
    bdbf5000-bdbfe000 r-xp 00000000 00:00 39997     /libexec/ld.elf_so
    bdbfe000-bdc00000 rw-p 00000000 00:00 0       [ anon ]
    bdc00000-bfa00000 ---p 00000000 00:00 0       [ stack ]
    bfa00000-bfbe0000 rwxp 00000000 00:00 0       [ stack ]
    bfbe0000-bfbf0000 rwxp 00000000 00:00 0       [ stack ]
    bfbf0000-bfc00000 rwxp 00000000 00:00 0       [ stack ]

and as you can plainly, see, there is only one area now, [3], into
which either of them can grow.  this means (or will mean, ultimately),
that your heap can grow larger, or you can mmap() larger objects.

note: currently this is only offered as an option for the i386
platform, though other platforms are expected to follow.  if you want
to try it out, add "options USE_TOPDOWN_VM" to your kernel config
file, rerun config, rebuild your kernel, and reboot.  in the future,
this option will probably disappear as platforms switch to using it
unconditionally.

as always, if you have any trouble with this, use send-pr(1) to report
it.

thanks.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."