Hi,

Darrin B. Jewell wrote:
> I've recently been working on the problems which are described in pr
> kern/24596 after independently observing the same large backlogs of
> unflushed pages.  My current fix for this is to add a new trickle sync
> page daemon, which walks a list of dirty pages similar to the active
> and inactive lists and flushes them out to disk slowly over timestamp
> based window.  This is working fine and does in fact solve the problem
> discussed in that pr as well as adding a smoother trickle sync
> than can be had by flushing an entire file at a time.

A trickle sync would take care of part of the problem #2 and #3 
of kern/24596. (The on disk inode update would be delayed for ufs
if the vnode is not on the sync list)

I am wondering how you define "a list of dirty pages".

For synchronization purposes I view pages as being in one of 
four states:

1) Clean and not write mapped
2) Unknown clean state and write mapped
3) Known dirty and write mapped
4) Dirty and not write mapped.

State 2 is tricky.
Constructing a (timely) dirty page list would require periodic
inspection of the clean state through the pmap layer.
Unless the number of pages in state 2 is restricted - this might
add up to a huge number of pages to check periodically.
Because UVM currently does not keep a list of pages
in state 2 (I have some plans to improve this) all (vnode) pages 
would need to be rechecked periodically.
How are you avoiding this expensive operation ?

	Stephan