It changed a little, but we still have it:
1) we do not deactivate active file pages if the active file
list is smaller than the inactive file list - this protects
the working set from streaming IO
2) we keep mapped referenced executable pages on the active file
list if they got accessed while on the active list, while
other file pages get deactivated unconditionally
I suspect it does, but I have not actually tested that code
in years :)
For one, memory sizes today are a lot larger than they were
when 2.6.0 came out.
Secondly, we now know more exactly what is on each LRU list.
That should greatly reduce unnecessary turnover of the list.
For example, if we know there is no swap space available, we
will not bother scanning the anon LRU lists.
If we know there is not enough file cache left to get us up
to the zone high water mark, we will not bother scanning the
few remaining file pages.
Because of those simple checks (in get_scan_priority), I do
not expect that we will have to scan through all of memory
as frequently as we had to do in 2.6.0.
Furthermore, we unconditionally deactivate most active pages
and have a working used-once scheme for pages on the anon
lists. This should also contribute to a reduction in the
number of pages that get scanned.
We have other measures in place now to protect the working set
on the file LRU lists (see above). We are able to have those
measures in the kernel because we no longer have mixed LRU
lists.
--
All rights reversed
--
