![]() | |||||||||||||
Messages in this thread |
Rik van Riel wrote: > Nick Piggin wrote: > >> The other nice thing about it was that it didn't have a hard >> cutoff that the current reclaim_mapped toggle does -- you could >> opt to scan the mapped list at a lower ratio than the unmapped >> one. Of course, it also has some downsides too, and would >> require retuning... > > Here's a simple idea for tuning. > > For each list we keep track of: > 1) the size of the list > 2) the rate at which we scan the list > 3) the fraction of (non new) pages that get > referenced > > That way we can determine which list has the largest > fraction of "idle" pages sitting around and consequently > which list should be scanned more aggressively. > > For each list we can calculate how frequently the pages > in the list are being used: > > pressure = referenced percentage * scan rate / list size > > The VM can equalize the pressure by scanning the list with > lower usage less than the other list. This way the VM can > give the right amount of memory to each type. > This sounds like a good thing to start with. I think we can then use swappiness to decide what to evict. > Of course, each list needs to be divided into inactive and > active like the current VM, in order to make sure that the > pages which are used once cannot push the real working set > of that list out of memory. > Yes, that makes sense. > There is a more subtle problem when the list's working set > is larger than the amount of memory the list has. In that > situation the VM will be faulting pages back in just after > they got evicted. Something like my /proc/refaults code > can detect that and adjust the size of the undersized list > accordingly. > > Of course, once we properly distinguish between the more > frequently and less frequently accessed pages within each > of the page sets (mapped/anonymous vs. unmapped) and have > the pressure between the lists equalized, why do we need > to keep them separate again? > :-) -- Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2007-01-23 07:33 [from the cache] ©2003-2008 | |||||||||||||