Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.arch
Subject: Re: VM needed for rapid startup
Message-ID: <11898@mimsy.UUCP>
Date: 10 Jun 88 05:45:57 GMT
References: <19730@beta.UUCP> <4332@killer.UUCP> <802@elxsi.UUCP> <20128@beta.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31

In article <20128@beta.UUCP> jlg@beta.UUCP (Jim Giles) writes:
>And (in spite of suggestions) there is NO commercial machine presently
>available which even takes 'hints' about the data usage patterns.  Even
>if such a machine DID exist, the best it could do is tie the speed of
>the non-VM code which does its own asynchronous paging.

I will agree with the latter, but I think not with the former.

/*
 * Copyright (c) 1982, 1986 Regents of the University of California.
 * All rights reserved.  The Berkeley software License Agreement
 * specifies the terms and conditions for redistribution.
 *
 *	@(#)vadvise.h	7.1 (Berkeley) 6/4/86
 */

/*
 * Parameters to vadvise() to tell system of particular paging
 * behaviour:
 *	VA_NORM		Normal strategy
 *	VA_ANOM		Sampling page behaviour is not a win, don't bother
 *			Suitable during GCs in LISP, or sequential or random
 *			page referencing.
 *	VA_SEQL		Sequential behaviour expected.
 *	VA_FLUSH	Invalidate all page table entries.
 */

(Now, the *implementation* of VA_SEQL may leave rather much to be
desired....)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris