On Sat, Sep 24, 2011 at 03:31:02AM +0000, YAMAMOTO Takashi wrote: > pagedaemon flushes dirty pages by itself, yes.
I added a printf() at the beginning of puffs_vnop_strategy() to check for calls by kernel threads. Only ioflush calls puffs_vnop_strategy(), pagedaemon never goes there. This may explain why the system cannot cope with PUFFS and memory shortage. An interesting point: if I use PDPOLICY_CLOCKPRO, then pagedaemon does call puffs_vnop_strategy(), through the path below. I understand this is the way it is supposed to work: puffs_vnop_strategy VOP_STRATEGY genfs_do_io genfs_gop_write genfs_do_putpages genfs_putpages VOP_PUTPAGES (through pgo->pgo_put) uvm_pageout The system still gets stuck after a while, with glusterfsd sleeping forever in flt_noram1. ddb' show uvmexp shows 3 free pages, 509 paging. If I understand correctly, pagedaemon performs an asynchronous VOP_STRATEGY and count an operation stuck in the PUFFS filesystem as paging. It decides to do more work if uvmexp.free + uvmexp.paging gets too low. therefore with many PUFFS page forever in the paging count, pagedaemon will not help us. I have a patch that maintain a count of paging to remote filesystems (that is, the one that do not have MNT_LOCAL in struct mount mnt_flag), and substract it from uvmexp.paging when pagedaemon has to decide whether to send more pages to the swap. It seems to work fine, but the system hang with perfused awaiting for km_getwait2 (from sys_write/putter_fop_write) -- Emmanuel Dreyfus m...@netbsd.org