Well, in the absence of of benchmark evidence its hard to tell how
valuable the usual criteria really are. That's another topic though,
because the question here is not how the aging matches up, but how the
inactive queue handling matches up, see below.
> > The page gets unmapped and added to the swap cache the first
> > time it wasn't referenced by the process.
> >
> > This is before any page aging is done.
>
> Actually there has been aging done. Unless you completely disable
> testing for pte_young. It is a different kind of aging but it is
> aging.
In the case of a process page and in the case of a file IO page the
situation is the same: we have decided to put the page on trial. Once
we have arrived at that decision its previous history doesn't matter,
so it makes sense to set its age to a known state. In this case it's
0, meaning "on trial".
Consider that the process page will only ever be down-aged after being
unmapped. So if we put it on the active queue, it just acts like a
big, slow, inefficient timer. Why not put it on a fifo queue instead?
It's the same thing, just more efficient. But we already have a fifo
queue, the inactive_dirty_queue, which we are using for everything
else, so why not use it for this too, then at least we know its fair.
In other words, there is no obvious need to treat a process page
differently from a file IO page once decide to put it on trial.
There does seem to be a dangling thread here though - when a process
page is unmapped and added to swap cache in try_to_swap_out then later
faulted back in, I don't see where we "rescue" the page from the
inactive queue. Maybe I'm just not looking hard enough.
-- Daniel - 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/