From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 23-DEC-1993 08:54:01.50
To:	EVERHART
CC:	
Subj:	Re: Desc. of V6.0 np-pool allocator (was Upgrading to VMS 6.0)

Message-Id: <9312230934.AA25426@uu7.psi.com>
Date: Tue, 14 Dec 1993 15:50:02 GMT
From: system@meng.ucl.ac.uk (Mark Iline)
To: Info-VAX@kl.sri.com, claborn@vmsdev.enet.dec.com
Subject: Re: Desc. of V6.0 np-pool allocator (was Upgrading to VMS 6.0)
X-Vms-To: MAIL_INFO-VAX, SMTP%"claborn@vmsdev.enet.dec.com"

Thanks to George for the description.

However, something about the new scheme struck a chord. I have this vague 
recollection that under the old scheme, there is a scenario whereby a code 
thread running at elevated IPL can fail to allocate NP pool, putting the 
system into a rather 'bad position'. Certain features of the new scheme 
look like they would make it worse.

This may be based on myth or misunderstanding, but here goes.

Allocating memory off the look-aside lists is done by a single (VAX) 
interlocked queue instruction. Because this instruction contains its own 
synchronisation, no other synchronisation (eg raising IPL) is necessary. As 
well as making this operation very fast, it also allows memory to be 
allocated from these lists at any IPL (to use IPL synchronisation, you must 
*raise* IPL to IPL_SYNCH. If you are running above IPL_SYNCH, you hava a 
problem.)

If the appropriate look-aside list is empty, some other action must be 
taken, either to extend the look-aside list, or to allocate from the other 
area of NP pool. Either of these require raising IPL for synchronisation 
purposes, so if the code thread is already running above IPL_SYNCH, you 
have a problem.

Under the old scheme, I would imagine that coming across an empty look-
aside list is quite rare. Firstly because their size is never reduced 
(except via a reboot). Secondly, because when they are extended (at least 
in the case of IRPs & SRPs), several packets are added to the list to make 
an integral number of pages (?).

Under the new scheme, because of the 30s reclamation, there is a gradual 
movement to the point where each list has one free packet (a simplistic 
view of a dynamic situation). I would have thought that a look-aside miss was 
quite likely. (Although the hit ratios seem to disagree with me).

Doesn't this make the scenario of an elevated IPL thread running into 
trouble more likely ? Have I got it all wrong, if so what ?


Mark

Mark Iline Sys Mgr Dept Mech Eng University College London UK
system@meng.ucl.ac.uk  		Read at your own risk.