Question about SystemPages in NT/2k/XP

[snakefoot 0]

I have been reading about the SystemPages registry entry, since a site reported that it would gain performance :

 

http://www.tweakxp.com/tweakxp/display.asp?id=301 (Though a little faulty since a page is 4 kb)

 

Well I looked in my own registry and found that my value (Win2k Adv. Srv. SP2 Without editing)

 

decimal = 503808 hex = 7b000

 

This puzzled me since this would equal it to 2 gb of memory.

 

When reading Tip 2356

 

http://www.jsiinc.com/SUBE/tip2300/rh2356.htm

 

It says that the display adapter would exhaust the system pages.

And that changing the value to 36000 decimal will solve it.

 

When reading the similar MS KB article :

 

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q226064

 

It says that one should "increase" the value to 36000 ? (Remember I have decimal value of 500000)

 

Also I looked at this other MS KB article

 

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q247904

 

It says that the 4gb memory is divided in two 2 gb parts (Process and Kernel allocation).

The kernel part is then divided in page pool and system pages.

The division between the page pool and system pages is fixed and cannot be changed after boot up.

And then says that when running server with Terminal Services one should "limit" the SystemPages value to 50000 or below.

If not limiting the SystemPages it will cause that only 50 users can connect to the Terminal Service.

 

This leaves me with some question, do you know the answer ?

 

Why are the first MS KB articles conflicting ? (Says that one should increase from 500000 to 36000 ?)

 

Why are the second MS KB article saying that one should give no value over 50000 ? (When default having 500000 ?)

 

Why are the default systempages value(2 gb) equal to the size of the kernel allocation (2 gb) ? (No use for page pool ?)

 

Hope you can help

 

-Rolf

[snakefoot 0]

Could it be that the size of SystemPages actually specifies the amount of non-paged kernel memory it is able to address ?

But since it is value which is not moving then it would mean that my system would be able to address 20480 pages of page pool kernel memory ?

 

Non-Page memory is used for timecritical things (Cannot be paged to disk)

 

Page pooled memory (Can be paged to disk)

 

So now my kernel is setup to only be able to page 80 mb of the kernel memory to the page file

 

Strange that the kernel services can live with only 80 mb of page pool memory.

 

Example according to the above articles the Terminal Service uses alot of the kernel Page pool memory.

[snakefoot 0]

Quote:

Originally posted by AlecStaar
Could be! This is one setting I have steered clear of, & have not even experimented with to be honest...

Same here always wondered what it meant, but now one says he gains performance. But the credibility of the advice is limited since he forgets that a page is 4 kbyte. So I wanted to check if anyone had any information of this registry entry.

Quote:

but I really DO think it can be used for granularity control of the diskcache itself, or ANY memory directed for System Use vs. UserMode application use (in combination with the other settings in that section, like LargeSystemCache in the registry MemoryManagement area).

It really depends of how it is implemented. I hope disk cache is not allowed to be paged, would be a really strange implementation . So one could actually limit how much RAM the kernel services should be able to grap (Without affecting the User Proces memory block). So if setting this value to 200 mb and using the entry LargeSystemCache(Server Service) then it should be limited to a 200 mb of RAM along with rest of the of kernel stuff. Avoiding the thing with exhausting memory when copying large files over a network. (Ofcourse this is just me guessing, as it requires that SystemCache means how much of the kernel memory block should be kept in memory)

Quote:

That is my understanding of it also... you can stop the kernel from paging itself though, with another entry in that area:

DisablePagingExecute (set that to Decimal 1)

As far I have read it is only the kernel core(Whatever that is) and drivers which is forced to be kept in memory.

Quote:

Others that are probably in play there are (just from their names & I am SURE you agree) are:

IoPageLockLimit (this one I know & work with)

This should be on the User Proces level(Not in kernel memory block). Assigning a certain amount of memory for each user proces.

Quote:

NonPagedPoolQuota (this one I have read about, but steer clear of)

NonPagedPoolSize (this one I have read about, but steer clear of)

PagedPoolSize (this one I have read about, but steer clear of)

I hope these entries specify how the memory management is for all of the 4 gb of memory and not just the kernel block.

Quote:

And, with Terminal Server?

SessionPoolSize (never worked with it)

SessionViewSize (never worked with it, DIRECTLY, in the registry at least)

I haven't used Terminal Server, but most of the articles, I have found about SystemPages, is about the terminal server and the problems about getting enough memory for it.

Quote:

This is a LONG read in this reply BUT DO READ IT, it may help you understand how this madness works at a VERY low level:

Sounds like something was really fubar. But I guess that is I/O programming in a nutshell.

Quote:

P.S.=> Snakefoot, I would like to hear more here on how your experimentations there go with those settings

I'm just looking into this to satisfy my curiosity. I'm not trying to solve some problem, besides finding out why the information about this little entry is a bit conflicting.

I think I will find some one to do a single experiment for me and that is to enable LargeSystemCache and at the same time limit the SystemPages. And then see if it will avoid the memory hogging thing when copying large files.

[capoguy 0]

up

 

Any new information about subject would be nice.

 

In many places it's recommended to set it as small as possible though why and what happens when the limit is exceeded? For ATI Radeon videocards dword:0xfffffff was presentetd as "atitweak" wich is a bit controversial couse in decimals it's 4294967295, thats like ~5377 times bigger than my original 798720.