Re: current paging strategy
On Thu, Nov 02, 2000 at 12:45:30AM -0800, David Greenman wrote: Interesting. THis needs about two bytes per page for the counter? Actually, we found that a single byte per page was sufficient. Pages tended to be either heavily accessed or rarely accessed. Even in the unusual case where all pages are frequently accessed, the page reclaim rate (and thus adjustment rate of the page references count) increases high enough to still provide for a decent distribution of the counters and for the page LOU to be effective. One byte sounds good for i386. Maybe it makes sense to have it 4 or 8 byte on risc platforms. I wonder if it's a critical path and if there are more of this in the kernel source. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
what exacly do you mean with critical path, here? JAn On Sun, 5 Nov 2000, Bernd Walter wrote: On Thu, Nov 02, 2000 at 12:45:30AM -0800, David Greenman wrote: Interesting. THis needs about two bytes per page for the counter? Actually, we found that a single byte per page was sufficient. Pages tended to be either heavily accessed or rarely accessed. Even in the unusual case where all pages are frequently accessed, the page reclaim rate (and thus adjustment rate of the page references count) increases high enough to still provide for a decent distribution of the counters and for the page LOU to be effective. One byte sounds good for i386. Maybe it makes sense to have it 4 or 8 byte on risc platforms. I wonder if it's a critical path and if there are more of this in the kernel source. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
On Mon, Dec 04, 2000 at 02:36:44PM -0700, [EMAIL PROTECTED] wrote: what exacly do you mean with critical path, here? Performance critical. Most RISC platforms are optimized for 32 and maybe 64 bit structures. E.g. First generation alphas (without BWX) can't even access anything smaller than 32bit in memory without doing big magic. So one byte can become a big impact on performance. On Sun, 5 Nov 2000, Bernd Walter wrote: On Thu, Nov 02, 2000 at 12:45:30AM -0800, David Greenman wrote: Interesting. THis needs about two bytes per page for the counter? Actually, we found that a single byte per page was sufficient. Pages tended to be either heavily accessed or rarely accessed. Even in the unusual case where all pages are frequently accessed, the page reclaim rate (and thus adjustment rate of the page references count) increases high enough to still provide for a decent distribution of the counters and for the page LOU to be effective. One byte sounds good for i386. Maybe it makes sense to have it 4 or 8 byte on risc platforms. I wonder if it's a critical path and if there are more of this in the kernel source. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
On Mon, Dec 04, 2000 at 11:41:26PM +0100, Bernd Walter wrote: On Mon, Dec 04, 2000 at 02:36:44PM -0700, [EMAIL PROTECTED] wrote: what exacly do you mean with critical path, here? Performance critical. Most RISC platforms are optimized for 32 and maybe 64 bit structures. E.g. First generation alphas (without BWX) can't even access anything smaller than 32bit in memory without doing big magic. So one byte can become a big impact on performance. One of the reasons anything EV56 falls out of favor by dBMS folks these days. -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
:On Mon, Dec 04, 2000 at 11:41:26PM +0100, Bernd Walter wrote: : On Mon, Dec 04, 2000 at 02:36:44PM -0700, [EMAIL PROTECTED] wrote: : what exacly do you mean with critical path, here? : : Performance critical. : Most RISC platforms are optimized for 32 and maybe 64 bit structures. : E.g. First generation alphas (without BWX) can't even access anything : smaller than 32bit in memory without doing big magic. : So one byte can become a big impact on performance. : :One of the reasons anything EV56 falls out of favor by dBMS folks these :days. : :-- :Wilko BulteArnhem, the Netherlands :[EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl sizeof(vm_page_t) is more critical. Bloating the structure eats a massive amount of memory, so messing around with all the short and char fields is out of the question even if we were to take a cpu hit. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
On Thu, Nov 02, 2000 at 12:45:30AM -0800, David Greenman wrote: Interesting. THis needs about two bytes per page for the counter? Actually, we found that a single byte per page was sufficient. Pages tended to be either heavily accessed or rarely accessed. Even in the unusual case where all pages are frequently accessed, the page reclaim rate (and thus adjustment rate of the page references count) increases high enough to still provide for a decent distribution of the counters and for the page LOU to be effective. One byte sounds good for i386. Maybe it makes sense to have it 4 or 8 byte on risc platforms. I wonder if it's a critical path and if there are more of this in the kernel source. No, space consumption of the vm_page data structure is by far the greatest concern. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
Interesting. THis needs about two bytes per page for the counter? Actually, we found that a single byte per page was sufficient. Pages tended to be either heavily accessed or rarely accessed. Even in the unusual case where all pages are frequently accessed, the page reclaim rate (and thus adjustment rate of the page references count) increases high enough to still provide for a decent distribution of the counters and for the page LOU to be effective. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current paging strategy
What paging strategy does FreeBSD currently use? Is it LRU or some approximation to it? How much memory does this strategy take up in its current implementation? Thank you for any information or links, Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
What paging strategy does FreeBSD currently use? Is it LRU or some approximation to it? How much memory does this strategy take up in its current implementation? It's probably nothing like anything you've heard of before. It's closest to LOU (least often used). We look at the page's reference flag and increment/decrement a counter depending on it. The rate that we look at the reference flag is also roughly proportional to the rate at which new pages are needed. This algorithm has proven to be extremely effective and does much better than simple LRU. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current paging strategy
Interesting. THis needs about two bytes per page for the counter? JAn On Wed, 1 Nov 2000, David Greenman wrote: What paging strategy does FreeBSD currently use? Is it LRU or some approximation to it? How much memory does this strategy take up in its current implementation? It's probably nothing like anything you've heard of before. It's closest to LOU (least often used). We look at the page's reference flag and increment/decrement a counter depending on it. The rate that we look at the reference flag is also roughly proportional to the rate at which new pages are needed. This algorithm has proven to be extremely effective and does much better than simple LRU. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
