Date: Fri, 03 Nov 2000 07:31:33 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: hackers@FreeBSD.ORG Cc: tlambert@primenet.com Subject: Re: vm_pageout_scan badness Message-ID: <00Nov3.083100est.115213@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
On Wed, 25 Oct 2000 21:54:42 +0000 (GMT), Terry Lambert <tlambert@primenet.com> wrote:
>I think the idea of a fixed limit on the FS buffer cache is
>probably wrong in the first place; certainly, there must be
>high and low reserves, but:
>
>|----------------------------------------------| all of memory
> |---------------------------------| FS allowed use
>|-------------------------------------| non-FS allowed use
>|------------| non-FSreserve
> |--------| FS reserve
>
>...in other words, a reserve-based system, rather than a limit
>based system.
This is what Compaq Tru64 (aka Digital UNIX aka OSF/1) does. It
splits physical RAM as follows:
|================================================| physical RAM
|====| Static wired memory
|===========================================| managed memory
|=---------------------------------| dynamic wired memory
|====-------------------------------------| UBC memory
|------------------------------------| VM
The default configuration provides:
- up to 80% of RAM can be wired.
- UBC (unified buffer cache) uses a minimum of 10% RAM and can use up
to 100% RAM.
- The VM subsystem can steal UBC pages if the UBC is using >20% RAM
There's no minimum limit for VM space. The UBC can't directly steal
VM pages, just pages off the common free list. The VM manages the
free list by paging and swapping based on target page counts (fixed
number of pages, not % of RAM).
The FS metadata cache is a fixed size wired pool.
I can think of benefits with the ability to separately control FS and
non-FS RAM usage. The Tru64 defaults are definitely a very poor match
with the application we run on it[1] and being able to reduce the RAM
associated with filesystem buffers is an advantage.
[1] Basically a number of processes querying a _very_ large Oracle SGA.
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00Nov3.083100est.115213>