More VMS 7.3-2 PQL_WS issue

[Doug Phillips]

I would really like to know more about this issue. As I understand,

1. these param values are in Pagelets,
2. the default for PQL_DWSQUOTA is 2048
3. the default for PQL_DWSDEFAULT IS 1024.

Normally these are set higher but I've never had a need to set the values as high as 65568 pagelets.

How does the N*PAGESIZE+32 calc fit into a system running at, say 2*default value.

And, I'd love to hear someone from HP discuss this problem in some depth?

Doug Phillips

[John Eerenberg]

Hi Doug,

> " I would really like to know more . . ."
I assume we are talking about VMS on alpha.

> "1. these param values are in Pagelets,"
One pagelet is 512 bytes, 16 pagelets equals one alpha page (which is 8K byte).

> "2. the default for PQL_DWSQUOTA is 2048"
> "3. the default for PQL_DWSDEFAULT IS 1024."
SYSGEN displays both pagelets and pages. Even on a small memory system (128MB for example), it is not unusual to have these parameters set to 8 times the sysgen default.

> "Normally these are set higher but I've never had a need to set the values as high as 65568 pagelets."
Autogen sets these two parameters reasonable well in many cases. And note that they can be set to values much higher then 65568. btw - where did 65,568 come from? Or did you mean 65,536?

> "How does the N*PAGESIZE+32 calc fit into a system running at, say 2*default value."
Not sure what you mean. How is N defined? Is "default" SYSGEN's default?

> "And, I'd love to hear someone from HP discuss this problem in some depth?"
I am not sure there is a problem here.
These parameters *in SYSGEN* have small defaults to support the lowest common demoninator system configuration (no, I don't work for HP). It certainly is not meant to be used much longer then it takes to install VMS and boot it the first or second time.

On the otherhand, Autogen examines a given system configuration and sets these PQL parameters; this is what I call the "default" for a given system. Further tuning can be done after that.

[Doug Phillips]

John,

Sorry, I should have posted a link to the original article. see:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=574666

You will find the answers to your questions there, whilest I, on the other hand, will not.

Doug

[John Eerenberg]

Bizzare!

Does anyone know if they enabled granularity hints for processes? The 8 in 8*8192 falls into the 1, 8, 64, 512 page boundaries for GH.

> "And, I'd love to hear someone from HP discuss this problem in some depth?"

Yeah. Me too.

[Ian Miller.]

the default values are ok as they are below the 8k pagesize so are rounded up to a page. You specify a value in pagelets but the real value is always rounded up to the next page as memory is actually allocated in pages. The problem arises when a size is specified for PQL_DWSDEFAULT which is exactly a multiple of the alpha memory pagesize (8k).

[Doug Phillips]

the default values are ok as they are below the 8k pagesize so are rounded up to a page. You specify a value in pagelets but the real value is always rounded up to the next page as memory is actually allocated in pages. The problem arises when a size is specified for PQL_DWSDEFAULT which is exactly a multiple of the alpha memory pagesize (8k).


Hmm.

1024 pagelets x 512 = 524,288 bytes
524,288 bytes / 8192 = 64 pages

That looks like an even page boundary to me. I still don't get it.

Doug

[Ian Miller.]

I see what you mean. The default value of
PQL_DWSDEFAULT is 1024 pagelets = 64 pages.
(The default value of PQL_MWSDEFAULT is lower than this : 32 pages, so does not affect the result).
So I guess every V7.3-1 system should be checked before upgrading to V7.3-2 to ensure MODPARAMS.DAT (or another place) sets the PQL_DWSDEFAULT and PQL_MWSDEFAULT value appropraitely.

[Doug Phillips]

So, going back to the original thread, what was being computed by N*PAGESIZE+32? I thought it was the value for the PQL_DWS'. Does that mean the minimum value where N>0 would be 1*8192+32= 8224?

Is it that the number of pages should not be one of the magic 2^n numbers? Or, is this only a problem if the value is greater than some value?

I have a 7.3-2 upgrade to do soon I'd like to understand the problem.

Blindly plugging in numbers that I don't understand isn't something I feel comfortable with. I accept what autogen tells me and don't tinker with it unless I understand what the parameter does and how its value affects the system. BTW, autogen has never recommended a change to these two PQL values.

Doug

[Antoniov.]

Hi Doug,
reading your question:

the default for PQL_DWSQUOTA is 2048
[...]
N*PAGESIZE+32

For N=1 and pagesize in (4,8 or 16)
1*2048+32=2080
1*4096+32=4128
1*8192+32=8224
every value is bigger than default and default is always different from formula.
Now, becuase vms engineering are not dummies and they aren't absend-minded, I think it's no possible set a default so wrong as system crash :-O
I hope some vms engineer can post a little explanation how theese parameter inpact into system and in some case crash vms, I can't see direct effect.
Obviously I'm also referring to other thread about this problem.

@Antoniov

[Ian Miller.]

You should change PQL_DWSDEFAULT from default of 1024 (64x8192 i.e. N=64) to 1056 (64x8192 + 32)or higher value of N.

If PQL_MWSDEFAULT is higher than PQL_DWSDEFAULT then the result is a working set = PQL_MWSDEFAULT which is why the need to check that too.

As I said its due to a bug in the calculatation of the working set list size.

[Uwe Zessin]

Just a thought:
PQL_MWS... is the absolute minimum for any process on the system and PQL_DWS... is the default when PQL$_DWS... is not specified on the process quota list of SYS$CREPRC(), right?

What happens when somebody puts an invalid value on the SYSTEM or any other username in UAF or (s)he uses a bad value to $CREPRC() ?

[Jan van den Ende]

Uwe,

what do you call "Invalid"?
If you just mean: less then the specified SYSGEN param, then simply the HIGHER one of these values is used.
The sysgen value is just what the name implies; the MINIMAL value.
Any SUSUAF of CREPRC request for less simply gets the specified minimum.

Jan

[Doug Phillips]

Well, I guess I should know by now that my brain doesn't work too well on Fridays;-)

Okay, I've checked a couple of other systems and here's what I have:

System-1 Current Default
PQL_DWSDEFAULT 2032 1024
PQL_DWSQUOTA 4064 2048

System-2
PQL_DWSDEFAULT 2992 1024
PQL_DWSQUOTA 5984 2048

These values are not in modparams.dat nor params.dat but are in setparams.dat so autogen has obviously calculated them somehow.

Now, I guess, rather than the N*PAGESIZE+32 formula, I'd like to know what the bug in the swapper is doing, and how I can more easily tell if a value is going to cause a problem. I mean, rather than compute a new value, I'd like to verify that an existing one is okay.

And, shouldn't the PAGESIZE in the formula maybe be 16 rather than 8192 since we're after pagelets? Otherwise, are we really computing N*8192=bytes and then (bytes/512)+32 to get the value? Isn't +32 just adding 2 pages to the value and isn't that the same as (N+2)*PAGESIZE?

I still _suspect_ that avoiding an even 2^n value might be the key, but if so I'd like to learn why.

Maybe it'll all make sense next Tuesday. Mondays aren't much better thinking days than Fridays:;:-)

Doug

[Uwe Zessin]

invalid = e.g. 65535 which, according to the other thread results in a crash, right?

What happens when PQL_MWS... + PQL_DWS... are, lets say 2048, which will not cause a crash.

Then somebody tries to start a process with:

$CREPRC PQL$_WSDEFAULT=65535, PQL$_WSQUOTA=65535 ...

These values are higher than the system parameters, so they should take preceedence, no? Will that cause a crash, too?

[Ian Miller.]

my understanding of the problem is that the crash happens during system startup if PQL_DWSDEFAULT is an exact multple of the alpha pagesize. If PQL_MWSDEFAULT is higher than PQL_DWSDEFAULT then its the PQL_M value that is significant.

The crash has been seen in the initial boot (for autogen) after doing the upgrade. The workaround is to set the system parameters as described previously.

[Uwe Zessin]

Yes, but it looks to me like the system crashes when it tries to start the first process (SYSINIT?) who's core is not part of the bootstrap like SWAPPER. The SWAPPER gets an exception and that's it.

The workaround is to fiddle with the parameters. I wonder what happens when you try to start a process later on, but specifying those 'bad' parameter values for WSDEFAULT and WSQUOTA.

[Ian Miller.]

I don't know what will happen if you explictly create a process with a WSDEFAULT which is an exact multiple of 8k.

I know the fix is known within hp and I expect a released patch will include it soon.

[Willem Grooters]

Ian,


I don't know what will happen if you explictly create a process with a WSDEFAULT which is an exact multiple of 8k.


One of the VERY FIRST lessons I learned when getting a system developer, is to test _at_least_ the behaviour on:

- EXACT match
- One unit below match
- One unit above match

I now have the impression that even these basic tests haven't been done ???

Just another point - I haven't the books around - is what type these data is in memory: 16 or 32 or 64 bit? signed/unsigned?
I do expect that if the values from sysparams.dat don't fit, you're either in trouble (like Doug) or you have all kinds of unpredictable and untraceble errors.

(I know this is not an answer for Doug, more a sign of concern about the quality of VMS)

Willem

[Doug Phillips]

Well, here it is Monday and I don't seem to be any wiser.

I see above at least three interpretations of the formula N*PAGESIZE+32 and they all make different assumptions about what N and PAGESIZE mean.

Ian, you say "exact multiple of page size", and "to set the system parameters as described previously".

The PQL_ values in question are in pagelets. The examples of the formula previously described above and in the original thread mix byte and pagelet values without explanation:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=574666

So for instance, our settings for WSDEFAULT and WSQUOTA were 65535. This worked out to be 65535/8192 or 7.99. The correct number to work around this problem would then be 8*8192+32 or 65568.


Does that mean that if the values in question are under 8192 pagelets then there is not a problem?

I guess the people at HP who actually know what's going on aren't going to respond. I don't think I have time to just play around with the parameters, seeing whether or not the system crashes on boot or not, so I'll just make my own assumptions and hope for the best.

Doug

[Ian Miller.]

The value you specify will be rounded up to the next page boundry. I think this is important butI'm not sure how.

[Antoniov.]

No dubt,
every allocation of page memory is boundary of pagelet, it's intrinsic in memory management.
Pagelet can be 4, 8,16 32 o 64Kb (they are always 2**n of a vax page).
For this reason, in my mind, PQL_* parameters can't be very high critical; however may be a combination of PQL_* parameters and some other value; for example what is the pagelet size where system crashed?
Does runned AUTOGEN and seen into report written?
Hein or some other vms engineer can discuss this problem with us?

@Antoniov

[Doug Phillips]

Pagelet can be 4, 8,16 32 o 64Kb (they are always 2**n of a vax page).


I guess I missed this change in VMS. My understanding has been that:

-For all systems, 1 Alpha Pagelet is 512 bytes, which equals 1 VAX page.

-For a particular system, 1 Alpha Page will be either: 8KB, 16KB, 32KB or 64KB.

I've only ever worked with 8KB pagesized Alphas.

Doug

[John Eerenberg]

> "I guess I missed this change in VMS. My understanding has been that:
-For all systems, 1 Alpha Pagelet is 512 bytes, which equals 1 VAX page.
-For a particular system, 1 Alpha Page will be either: 8KB, 16KB, 32KB or 64KB."

Alpha pages are never refered to as pagelets; they are always 8KB and called pages. A VAX page is 512 bytes and on the Alpha when you say "pagelets" you are talking about how a VAX page translates into an alpha page which is 16 pagelets equals 1 page.

So this is a chip architecture change and VMS was modified to understand a VAX page from an Alpha page.

> "I've only ever worked with 8KB pagesized Alphas."
8KB is the only size for the Alpha. Assuming the plans don't change for moving Alpha to Itanium, the 16KB, 32KB, and 64KB pages will never be implemented.

[Steve Reece]

"8KB is the only size for the Alpha. Assuming the plans don't change for moving Alpha to Itanium, the 16KB, 32KB, and 64KB pages will never be implemented. "

There were suggestions that this wouldn't be the case with Marvel systems due to the large amounts of memory that they supported. I'd see a similar argument put forward in the future for IA64 systems supporting large memory.

[Antoniov.]

John,
sorry, I disagree with you; you posted:
"Alpha pages are always 8KB"
this was true in first version of Alpha Vms; now the size of page may be 4 values; you can read this section of HP documentation http://h71000.www7.hp.com/doc/732FINAL/aa-pv5mh-tk/aa-pv5mh-tk.HTMl referring V7.3-2.
If my mind doesn't fault, in first version of alpha/vms, pagelet could be 4k too, but I'm not sure of this.
However, the pagelet cannot never be 512 bytes, too small for AXP.

@Antoniov