--8GpibOaaTibBMecb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=
=20
> as sequential
> access/random access ? Thus the file page sub class could be further=20
> divided in
> sequential pages and random access pages.

Probably.

> 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,=
=20
should get set for re-use sooner. I'm not fully sure the best way to do=20
that. :-)

> A related strategy seems the exist in Solaris 8, where sequential access=
=20
> 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.

Take care,

Bill

--8GpibOaaTibBMecb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAyKcqWz+3JHUci9cRArH4AKCCtixVkqCHtdmIN5dkJbMc2IWI5QCgitiP
70uGfgTGu4kDiCXOsao7HSM=
=qodh
-----END PGP SIGNATURE-----

--8GpibOaaTibBMecb--