On Wed, 25 Oct 2000 21:54:42 +0000 (GMT), Terry Lambert <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
