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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to