Messages in this thread | | | Date | Mon, 23 Feb 2009 01:37:23 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH 20/20] Get rid of the concept of hot/cold page freeing |
| |
On Sun, 22 Feb 2009 23:17:29 +0000 Mel Gorman <mel@csn.ul.ie> wrote:
> Currently an effort is made to determine if a page is hot or cold when > it is being freed so that cache hot pages can be allocated to callers if > possible. However, the reasoning used whether to mark something hot or > cold is a bit spurious. A profile run of kernbench showed that "cold" > pages were never freed so it either doesn't happen generally or is so > rare, it's barely measurable. > > It's dubious as to whether pages are being correctly marked hot and cold > anyway. Things like page cache and pages being truncated are are considered > "hot" but there is no guarantee that these pages have been recently used > and are cache hot. Pages being reclaimed from the LRU are considered > cold which is logical because they cannot have been referenced recently > but if the system is reclaiming pages, then we have entered allocator > slowpaths and are not going to notice any potential performance boost > because a "hot" page was freed. > > This patch just deletes the concept of freeing hot or cold pages and > just frees them all as hot. >
Well yes. We waffled for months over whether to merge that code originally.
What tipped the balance was a dopey microbenchmark which I wrote which sat in a loop extending (via write()) and then truncating the same file by 32 kbytes (or thereabouts). Its performance was increased by a lot (2x or more, iirc) and no actual regressions were demonstrable, so we merged it.
Could you check that please? I'd suggest trying various values of 32k, too.
| |