Date: Wed, 13 Aug 1997 09:31:05 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Memory management details Message-ID: <199708131631.JAA12535@phaeton.artisoft.com> In-Reply-To: <19970813014802.27316.qmail@hotmail.com> from "Douglas Jardine" at Aug 12, 97 06:48:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 1)The mail archives seem to indicate that the latest versions of
> FreeBSD use a zone memory allocator which replaced the 4.4BSD
> buddy system allocator. Is this correct?
Midified zone. It *looks* like a MACH memory allocator because
most of the API's have been maintained.
> 2)Is FreeBSD considering moving to a more simplified pmap module?
> Since it is customized to run only on i386 architeure, there
> doesn't seem to be any need for maintaining whatever extra fat
> the pmap module may have.
FreeBSD is planning on being run on other architectures. If one is
hopping around on his right foot, he doesn't shoot his left foot
just because he isn't currently using it. 8-).
> 3)FreeBSD uses Global-LRU for its page replacement. Is there any
> project in the FreeBSD community working towards a working-set
> type model?
I have argued for this for some time, citing the SVR4 "ld"'s worst
case behaviour (it mmap's the object files, and randomly accesses
them in memory). On SVR4, this causes the VM and buffer cache to
thrash between them, as well as allowing particular files to
monopolize available memory.
FreeBSD is somewhat tolerant of this. First, it has a unified VM
and buffer cache, so the VM and buffer cache systems are never
at odds over memory: it is identical. Second, FreeBSD agressively
prefers swap to LRU discard of pages; this means that it will
appear as if the swap is fully utilized on even a lightly loaded
system, after some moderate activity. But it means that the LRU
locality is increased by being amortized over real memory + swap,
instead of just over real memory.
Nevertheless, it would be a good idea to implement working set
quotas to prevent worst case denial of service attacks, which
though more difficult in FreeBSD, are still rather trivial to
code up.
The simplest method of implementing a working set is to establish
it on a per vnode rather than on a per process basis. This is
because the unified cache means that pages hung off a vnode are
shared between multiple processes on the vnode. If process A is
over quota, culling pages from a vnode shared with process B (this
is what VMS does to pagefile pages, and, I believe what NT does) is
a bad idea. Instead, if you establish a per vnode working set
quota, you prevent a particular vnode from monopolizing system
resources.
This is pretty trivial to implement, since it is a tiny modification
in the vnode page replacement algorithm, to steal LRU pages from
the vnode itself instead of the global LRU, once the vnode hits
quote. The catch is that you must maintain a page count, as well
as a page chain, and that a global LRU steal for a global resource
shortage must adjust the count on the vnode stolen from. Basically,
it's a no-brainer.
I implemented something similar to this in the UnixWare 2.0 VM
system to try and get around the "move mouse, wiggle cursor"
bug, where if an ld was going on, the pages for the X server
were swapped out. Even a trivial implementation worked
*remarkably* well.
Novell/USG (USL) elected to put the X server in a seperate
scheduling class ("fixed") instead, as their soloution. I still
believe this was an error.
> 4)Or for that matter a project to add "swap files"? What is the
> maximum number of swap partitions allowed by the architecture?
It's already in there.
> Get Your Private, Free Email at http://www.hotmail.com
Hopefully you are a list subscriber -- I have removed your "hotmail"
address from my response address list.
You should be aware that "hotmail", like "juno", is an address
harvester for people you send mail to or get mail from. As such,
people will be reluctant to communicate with you directly because
they don't want their email address sold to spammers.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708131631.JAA12535>