Subject: Re: page reuse while accessing files sequentially
To: Frank Kardel <Frank.Kardel@Acrys.COM>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/10/2004 11:23:38
Content-Type: text/plain; charset=us-ascii
On Fri, Jun 04, 2004 at 10:07:41AM +0200, Frank Kardel wrote:
> Would it make sense to categorize file pages with respect to their usage=
> as sequential
> access/random access ? Thus the file page sub class could be further=20
> divided in
> sequential pages and random access pages.
> A file(vnode) would start out as sequential access vnode until a=20
> decision can be made, that
> access is random. Indications could be:
> - the vnode is mmapped
Note that with UBC, ALL file reads & writes are done via vnode mappings.
> - non sequential access
> Pages allocated could be marked with the sequential/random information=20
> of the vnode they
> belong to. The sequential page pool could be limited separatly to keep=20
> it from monopolizing
> the file page pool. Even the executables (mmap property) could be=20
> handled that way without
> the need for an executable page class.
I think a better thing to do than have different pools is to have=20
"sequential" pages recycled differently than "random" ones. "Random" of=20
course really means "I may need this again," while "sequential" means "I=20
really really don't think I'll need this again."
"Sequential" ones should get flushed sooner than later, and once flushed,=
should get set for re-use sooner. I'm not fully sure the best way to do=20
> A related strategy seems the exist in Solaris 8, where sequential access=
> leads to a FIFO
> replacement strategy. This might be dangerous though, as we did have=20
> once a state where
> our java vm was seemingly on the FIFO replacement strategy making work=20
> very slow :-( .
> This effect should be avoided.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----