Messages in this thread | | | Date | Thu, 26 Feb 2009 12:00:22 -0500 (EST) | From | Christoph Lameter <> | Subject | Re: [PATCH 20/20] Get rid of the concept of hot/cold page freeing |
| |
On Thu, 26 Feb 2009, Mel Gorman wrote:
> The known-to-be-zeroed pages is interesting and something I tried but didn't > get far enough with. One patch I did but didn't release would zero pages on > the free path if the was process exiting or if it was kswapd. It tracked if > the page was zero using page->index to record the order of the zerod page. On > allocation, it would check index and if a matching order, would not zero a > second time. I got this working for order-0 pages reliably but it didn't gain > anything because we were zeroing even more than we had to in the free path.
I tried the general use of a pool of zeroed pages back in 2005. Zeroing made sense only if the code allocating the page did not immediately touch the cachelines of the page. The more cachelines were touched the less the benefit. If the page is written to immediately afterwards then the zeroing simply warms up the caches.
page table pages are different. We may only write to a few cachelines in the page. There it makes sense and that is why we have the special quicklists there.
> If pagetable pages were known to be zero and handed back to the allocator > that remember zerod pages, I bet we'd get a win.
We have quicklists that do this on various platforms.
| |