> 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)?

i haven't done any serious comparison.

> ... 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.

how is it better than making inactive queue longer?

> > 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?

i don't think it's a problem at this point, given that
there are no ->A loan users in tree.

there are some kinds of access to a page.
	1. loaned read
	2. normal read without fault
	3. normal read with fault

#1 and #3 activate the page.
#2 and #3 set the reference bit.

if pagedaemon clears the reference bit when inactivating the page,
#1 and #3 survives 1 page queue cycle.
however, with the current scheme, #3 survives two times longer than #1.
it's what i said unfair.

> 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.)

i agree that current double tracking of these bits is not very pretty.

YAMAMOTO Takashi