On Wed, 7 Nov 2007 09:59:45 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 6 Nov 2007 21:51:27 -0500 Rik van Riel <[EMAIL PROTECTED]> wrote: > > Which is why we need to greatly reduce the number of pages > > scanned to free a page. In all workloads. > > It strikes me that splitting one list into two lists will not provide > sufficient improvement in search efficiency to do that. Well, if you look at the typical problem systems today, you will see that most of the pages being allocated and evicted are in the page cache, while most of the pages in memory are actually anonymous pages. Not having to scan over that 80% of memory that contains anonymous pages and shared memory segments to get at the 20% page cache pages is much more than a factor two improvement. > I mean, a naive guess would be that it will, on average, halve the amount > of work which needs to be done. > > But we need multiple-orders-of-magnitude improvements to address the > pathological worst-cases which you're looking at there. Where is this > coming from? Replacing page cache pages is easy. If they were referenced once (typical), we can just evict the page the first time we scan it. Anonymous pages have a similar optimization: every anonymous page starts out referenced, so moving referenced pages back to the front of the active list is unneeded work. However, we cannot just place referenced anonymous pages onto an inactive list that is shared with page cache pages, because of the difference in replacement cost and relative importance of both types of pages! > Or is the problem which you're seeing due to scanning of mapped pages > at low "distress" levels? > > Would be interested in seeing more details on all of this, please. http://linux-mm.org/PageReplacementDesign -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/