On Thu, Aug 25, 2005 at 11:52:10AM +0900, YAMAMOTO Takashi wrote:
> hi,
> 
> in uvm_pdaemon.c 1.37, you removed pmap_clear_reference from uvmpd_scan.
> i think that it makes a page allocated by a single fault survive
> until page queue cycles twice at least.
> is it an intended behaviour?

apparently I intended something at the time, since there's a corresponding
change in uvmpd_scan_inactive() in that revision (changing pmap_is_referenced()
to pmap_clear_reference()).  I don't recall why I did it, though,
and it's not mentioned in my massive commit comment, alas.

I agree that that change would keep pages around longer than the previous
mechanism for clearing the referenced bit.  does changing that back
make any detectable difference (either in measurable performance or
in a double-blind test of subjective performance)?

... actually, I think I remember now.  the active and inactive lists contain
2/3 and 1/3 of pageable pages respectively, so a page will spend 2/3 of a
page queue cycle on the active list.  clearing the referenced bit on the
transition from active to inactive ignores any references made during that
2/3 of the cycle, which seemed like it would throw away pages too soon.
the current scheme requires that a page remain unreferenced for an entire
page queue cycle before the pagedaemon will reclaim it, which gives referenced
pages a better chance to survive, at the cost of some additional CPU usage by
the pagedaemon.  I don't know whether the tradeoff is really worth it, though.


> it's at least unfair for page-loaning, which doesn't set a reference bit.

if a page is loaned, "freeing" it just transfers ownership to the loanee,
so the loanee isn't penalized for this.  the loaner would have to go read
the page from backing store again the next time it's accessed, which would
be especially bad if the logical page is only ever accessed via loans.
but this problem still exists regardless of when the pagedaemon clears
the referenced bit.  is that the problem that you were talking about,
or did you mean something else?

ideally, accesses to a page via loan mappings would set the referenced bit
just like accesses via normal mappings, but that would need a big design change.
for now, we at least ought to have creation of a new loan set the referenced
bit on a page.  even that would want a new pmap interface
(eg. pmap_set_reference()), but at least that would be non-intrusive to
the rest of the system.  (on a related note, I'd also like to get rid of
PG_CLEAN in favor of keeping all the page-dirty info in the pmap, which would
need a pmap_set_modify() as well.  seems nice and symmetric, and it should
be simpler than having the dirty info spread across both UVM and pmap layers.)

-Chuck