Optimization for use-once pages
A message that is not in the archive (sent off-list or not yet received): 0107251802300B.00907@starship
Quoted 7 lines · Daniel Phillips
Quoted 2 lines · Marcelo Tosatti
Now I'm not sure why directly adding swapcache pages to the inactive dirty lits with 0 zero age improves things.
Because it moves the page rapidly down the inactive queue towards the ->writepage instead of leaving it floating around on the active ring waiting to be noticed. We already know we want to evict that page,
We don't.
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.
Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"
http://www.surriel.com/
Quoted 10 lines · Rik van Riel
Quoted 8 lines · Daniel Phillips
Quoted 2 lines · Marcelo Tosatti
Now I'm not sure why directly adding swapcache pages to the inactive dirty lits with 0 zero age improves things.
Because it moves the page rapidly down the inactive queue towards the ->writepage instead of leaving it floating around on the active ring waiting to be noticed. We already know we want to evict that page,
Quoted 6 lines
We don't.
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.
True, it's more accurate to say that we already know we want to *try* evicting that page. A wrong guess should not make it all the way down the inactive queue.
--
Daniel
Quoted 10 lines · Rik van Riel
Quoted 7 lines · Daniel Phillips
Quoted 2 lines · Marcelo Tosatti
Now I'm not sure why directly adding swapcache pages to the inactive dirty lits with 0 zero age improves things.
Because it moves the page rapidly down the inactive queue towards the ->writepage instead of leaving it floating around on the active ring waiting to be noticed. We already know we want to evict that page,
We don't.
Agreed. The kinds of ``aging'' don't match up so we can't tell if it meets our usual criteria for aging.
Quoted 4 lines
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.
Eric
Quoted 11 lines · Eric W. Biederman
Quoted 10 lines · Rik van Riel
Quoted 8 lines · Daniel Phillips
Quoted 2 lines · Marcelo Tosatti
Now I'm not sure why directly adding swapcache pages to the inactive dirty lits with 0 zero age improves things.
Because it moves the page rapidly down the inactive queue towards the ->writepage instead of leaving it floating around on the active ring waiting to be noticed. We already know we want to evict that page,
Quoted 4 lines
Quoted 1 line
We don't.
Agreed. The kinds of ``aging'' don't match up so we can't tell if it meets our usual criteria for aging.
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.
Quoted 8 lines
Quoted 4 lines
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
Quoted 4 lines · Daniel Phillips
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_outthen 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.
do_swap_page()->lookup_swap_cache()->__find_page_nolock()->SetPageReferenced().
The referenced bit will make page_launder/reclaim_page move the page to the active list.
Quoted 11 lines · Marcelo Tosatti
Quoted 4 lines · Daniel Phillips
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_outthen 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.do_swap_page()->lookup_swap_cache()->__find_page_nolock()->SetPageRef
erenced().The referenced bit will make page_launder/reclaim_page move the page to the active list.
Yes. And there I set ->age to a known state (START_AGE), so everything seems to be in order.
--
Daniel