Messages in this thread | | | Date | Thu, 26 Feb 2009 17:15:49 +0000 | From | Mel Gorman <> | Subject | Re: [PATCH 20/20] Get rid of the concept of hot/cold page freeing |
| |
On Thu, Feb 26, 2009 at 12:00:22PM -0500, Christoph Lameter wrote: > 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.
Any feeling as to how often this was the case?
> 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. >
Indeed, any gain if it existed would be avoiding zeroing the pages used by userspace. The cleanup would be reducing the amount of architecture-specific code.
I reckon it's worth an investigate but there is still other lower-lying fruit.
-- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab
| |