Subject: Re: page replacement
To: None <chuq@chuq.com>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 12/14/2005 22:23:16
--NextPart-20051214192100-0057200
Content-Type: Text/Plain; charset=us-ascii

hi,

> > - page type balancing is disabled for simplicity.
> 
> did having this enabled or disabled affect the results?

as it "randomize" the order of pages in page queue,
results were somewhat unstable with it enabled, depends on amount of memory.

anyway, results with the default setting are here:
	vm.anonmin = 10 vm.execmin = 5 vm.filemin = 10
	vm.anonmax = 80 vm.execmax = 30 vm.filemax = 50
ftp://ftp.netbsd.org/pub/NetBSD/misc/yamt/2/ld.ps.gz
ftp://ftp.netbsd.org/pub/NetBSD/misc/yamt/2/ld_e.ps.gz
ftp://ftp.netbsd.org/pub/NetBSD/misc/yamt/2/ld_b.ps.gz

> > - Y-axis is the number of major faults when linking a kernel.
> 
> do you really mean just the link step of building a kernel,
> or the whole kernel build process?

only link step.

> I checked the access pattern of "ld" just now and it looks like ld makes
> 3 passes over all the object files, reading the whole file each time and
> writing data to the output file during the last pass.  I would guess that
> the desired paging behaviour for this access pattern would be to keep
> most of the process data in memory and cycle the .o file contents through
> the remaining memory.  can you tell if that's really what happens?

as ru_majflt doesn't include ubc faults and the number of i/o via genfs
doesn't seem vary much, yes, i think so.

ftp://ftp.netbsd.org/pub/NetBSD/misc/yamt/1/ld_b.ps.gz
(Y-axis is ru_inblock with the attached patch.
it's plotted from the same data as other graphs in the same directory.)

> I guess that the effect of clearing the reference bit when moving a page
> from active to inactive is to discount the initial pages access the occurs
> when a page is first create.  only if a page is accessed again after some
> time would we consider it important enough to keep.  it's interesting that
> the shorter you make the period of "initial access" (ie. the longer you make
> the inactive queue), the better the result.  so my notion that gathering
> access info for longer was right, I just forgot that it's important to ignore
> the initial access.

yes, otherwise newly allocated pages are always reactivated once.
it makes old pages hard to compete.

YAMAMOTO Takashi

--NextPart-20051214192100-0057200
Content-Type: Text/Plain; charset=us-ascii
Content-Disposition: attachment; filename="a.diff"

Index: genfs_vnops.c
===================================================================
--- genfs_vnops.c	(revision 1464)
+++ genfs_vnops.c	(working copy)
@@ -829,6 +829,8 @@ genfs_getpages(void *v)
 		else
 			BIO_SETPRIO(bp, BPRIO_TIMECRITICAL);
 
+		curproc->p_stats->p_ru.ru_inblock++;
+
 		VOP_STRATEGY(devvp, bp);
 	}
 
@@ -1447,6 +1449,7 @@ genfs_gop_write(struct vnode *vp, struct
 	struct buf *mbp, *bp;
 	struct vnode *devvp;
 	boolean_t async = (flags & PGO_SYNCIO) == 0;
+	struct proc *p = curproc;
 	UVMHIST_FUNC("genfs_gop_write"); UVMHIST_CALLED(ubchist);
 
 	UVMHIST_LOG(ubchist, "vp %p pgs %p npages %d flags 0x%x",
@@ -1539,6 +1542,10 @@ genfs_gop_write(struct vnode *vp, struct
 			BIO_SETPRIO(bp, BPRIO_TIMENONCRITICAL);
 		else
 			BIO_SETPRIO(bp, BPRIO_TIMECRITICAL);
+
+		if (p) {
+			p->p_stats->p_ru.ru_oublock++;
+		}
 
 		VOP_STRATEGY(devvp, bp);
 	}

--NextPart-20051214192100-0057200--