About PTEs, VADs and PFN database

NTDEV
21

Maxim S. Shatskih wrote:

> create a VAD entry, but a commit will actually create VAD and
> corresponding PTE(s) ???
>

IIRC PTEs are created in a page fault path, but the PTEs which are described by VAD are zeroed to force MmAccessFault to consult the VAD tree.

@Max & Ken

Then the obvious question would be ( internally) what is the difference
between reserve and commit? Both will create the VAD(s) right?. Is the
commit, in addition to VAD creation will go reserve the page space in
page file?

Ah, that’s called totally rusty. Perhaps just rust :slight_smile:

-pro

22

> Then the obvious question would be ( internally) what is the difference

between reserve and commit? Both will create the VAD(s) right?. Is the
commit, in addition to VAD creation will go reserve the page space in
page file?

It will reserve some “commit charge” global counter value and also mark the VAD as committed.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

23

Never mind, reserve does not mean allocated. It’s just the address space
is reserved, nothing more!.
Commit means reserved and committed ( that is allocated ).

My brain is on sell , $.01

-pro

Prokash Sinha wrote:

Maxim S. Shatskih wrote:
>> create a VAD entry, but a commit will actually create VAD and
>> corresponding PTE(s) ???
>>
>
> IIRC PTEs are created in a page fault path, but the PTEs which are
> described by VAD are zeroed to force MmAccessFault to consult the
> VAD tree.
>
>
@Max & Ken

Then the obvious question would be ( internally) what is the
difference between reserve and commit? Both will create the VAD(s)
right?. Is the commit, in addition to VAD creation will go reserve the
page space in page file?

Ah, that’s called totally rusty. Perhaps just rust :slight_smile:

-pro

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

24

Maxim S. Shatskih wrote:

> Then the obvious question would be ( internally) what is the difference
> between reserve and commit? Both will create the VAD(s) right?. Is the
> commit, in addition to VAD creation will go reserve the page space in
> page file?
>

It will reserve some “commit charge” global counter value and also mark the VAD as committed.

Yes.

Also depending on the status (1) reseve (2) committed (3) backed etc.,
the traps and exeception handling would be different: Access violation,
page fault, protection violation etc. etc…

thanks everyone.

-pro

25

> @Pavel: You gave some insight about pointing PTE to page file ( when

context switched) instead of PFN. I don’t remember seeing anything in
Windows internals or File system book. Is there any documents that I can
follow?

These are called “software PTEs” in Windows. They are described in
Windows Internals - see the section on Invalid PTEs.

Here’s the corresponding Mm structure:

lkd> dt nt!_MMPTE_SOFTWARE
+0x000 Valid : Pos 0, 1 Bit
+0x000 PageFileLow : Pos 1, 4 Bits
+0x000 Protection : Pos 5, 5 Bits
+0x000 Prototype : Pos 10, 1 Bit
+0x000 Transition : Pos 11, 1 Bit
+0x000 UsedPageTableEntries : Pos 12, 10 Bits
+0x000 InStore : Pos 22, 1 Bit
+0x000 Reserved : Pos 23, 9 Bits
+0x000 PageFileHigh : Pos 32, 32 Bits

!pte knows about this PTE format and can dump it in user-readable
form.

–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.

26

> IIRC PTEs are created in a page fault path, but the PTEs which are

described by VAD are zeroed to force MmAccessFault to consult
the VAD tree.

PTEs themselves are allocated on demand in page-size chunks. So when
memory is initially committed, PTEs don’t even exist (unless they fall into
a PDE that is already being used by other allocations, in which case they
will exist, but will be set to 0).

–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.

27

I just read thru that section, and it makes sense now.

Aside: The problem I had in mind was to run set intersection on 10 to 15
pairs of sets ( like, A, A’; B, B’ …). And find the intersection of
those pairs. Each set could be very large ( i.e 1 to 10 Million
entries). Obviously there are algorithmic side ( sort and compare, hash,
and other families of set union and intersections …) and their
performance may vary depending on a number of factors: CPU strengths and
numbers, pageable & non pageable memory to use and other stuff…

Now I need to scribble some of the important aspects discussed here (
just to be conceptually bit more clear).

Thanks
-pro

Pavel Lebedinsky wrote:

> @Pavel: You gave some insight about pointing PTE to page file ( when
> context switched) instead of PFN. I don’t remember seeing anything in
> Windows internals or File system book. Is there any documents that I can
> follow?
>

These are called “software PTEs” in Windows. They are described in
Windows Internals - see the section on Invalid PTEs.

Here’s the corresponding Mm structure:

lkd> dt nt!_MMPTE_SOFTWARE
+0x000 Valid : Pos 0, 1 Bit
+0x000 PageFileLow : Pos 1, 4 Bits
+0x000 Protection : Pos 5, 5 Bits
+0x000 Prototype : Pos 10, 1 Bit
+0x000 Transition : Pos 11, 1 Bit
+0x000 UsedPageTableEntries : Pos 12, 10 Bits
+0x000 InStore : Pos 22, 1 Bit
+0x000 Reserved : Pos 23, 9 Bits
+0x000 PageFileHigh : Pos 32, 32 Bits

!pte knows about this PTE format and can dump it in user-readable
form.

28

>>It would be nice if you could plot out what are ( if any documents) you would suggest for someone to read.

I first encountered these structures in win intrnl few years back, I read it and leave it as there were some thing needs more attention than these structure’s internals(i am salaried ;-)). Few weeks back I started reading OSR’ device driver book by Mr. Peter and Mr. Tony and encountered them in more detail and felt something bugging me for more clarity. The MSDN article I got is “http://msdn.microsoft.com/en-us/library/ms810616.aspx”, its been written in 1992. Talks about basic *technical detail* and is straight on the point. It covers almost every thing about virtual memory in less than 20 pages.

Thanks,
Aditya

29

@Pavel

In the scenario given by you

  1. If process B has also allocated Y private pages, some of them will have to be paged out (because there are only X physical pages in total).

I got it.

  1. When process B runs again and references these pages,

It means that page directory and page tables are of process B now as other wise it can not reference them correctly.

3)the memory manager might trim some pages from process A, write their contents to the pagefile, change process A’s PTEs to point to the corresponding pagefile locations,

How will MM access process A’s PTE as CR3 is loaded with process B’s page directory. Any internal data structure?

4)and finally give the physical frames to process B,

So now it modifies this frame to point to process B’s PTE, correct ?

4)at which point it will also update PteAddress to point to process B’s PTEs.

Just for clarification, Do you mean pteaddress in page-frame entry?

Thanks for your time,
Aditya

30

@Anton

>WEll, you seem to have quite peculiar understanding of things

I agree, I was not able to put correct question as I was not considering that process A’s pte will become invalid and points to the page file before process B PTE points to PFN . My apologies.

Thanks,
Aditya

31

> How will MM access process A’s PTE as CR3 is loaded with process

B’s page directory. Any internal data structure?

Trimming is done by the working set manager thread which runs in the
context of the System process. When it decides to trim process A’s
pages, it will attach to that process’ address space using KeAttachProcess
(which will switch CR3 to point to process A’s directory base).

4)and finally give the physical frames to process B,

So now it modifies this frame to point to process B’s PTE, correct ?

Correct.

4)at which point it will also update PteAddress to point to process B’s
PTEs.

Just for clarification, Do you mean pteaddress in page-frame entry?

Yes.

–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.

32

@Pavel,

Thanks a lot, it really helps.

Aditya

33

!pte knows about this PTE format and can dump it in user-readable form.

I tried playing with it for further understanding of things,

!pte 0x7980020
VA 07980020
PDE at C0300078 PTE at C001E600
contains 07569867 contains 041AA847
pfn 7569 —DA–UWEV pfn 41aa —D—UWEV

for said address PDI is 0x1E and PTI is 0x180,

I used PDI to move to the exact page table, i,e, C001E000 and converted 0x180 index to bytes and reached the address C001E600.

But in doing this I did not need to use the page directory at all i.e. I did not need to route through C0300000. I verified that PDE value at index 0x1E is 07569867 as given by !pte but what after this. what information this will provide, I tried looking into contents by dumping it with !dd 7569 but did not reach to any definite conclusion. What information this PFN provides?

Thanks
Aditya

34

> But in doing this I did not need to use the page directory at all

See the information here:

!pte is doing extra work for you. See the "Converting Addresses By Hand"
section (and your local Intel reference manual) for more information.

tried looking into contents by dumping it with !dd 7569 but did not reach
to any definite conclusion.

FYI for PFNs you need to do:

!dd 7569*@$pagesize

Since the PFN is an index, not an address.

What information this PFN provides?

It's the PFN of the page table. So, for example:

0: kd> !pte f9934000
VA f9934000
PDE at 00000000C0603E60 PTE at 00000000C07CC9A0
contains 0000000001644963 contains 0000000007071121
pfn 1644 -G-DA--KWEV pfn 7071 -G--A--KREV

0: kd> * Dump the PTE contents

0: kd> dc 00000000C07CC9A0 l4
c07cc9a0 07071121 00000000 07072963 00000000 !.......c)......

0: kd> * Now dump the PFN of the PDE plus the page offset of the PTE

0: kd> !dc (1644*@$pagesize)+9a0 L4

16449a0 07071121 00000000 07072963 00000000 !.......c)......

-scott

--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.

wrote in message news:xxxxx@ntdev...
> !pte knows about this PTE format and can dump it in user-readable form.
>
> I tried playing with it for further understanding of things,
>
> !pte 0x7980020
> VA 07980020
> PDE at C0300078 PTE at C001E600
> contains 07569867 contains 041AA847
> pfn 7569 ---DA--UWEV pfn 41aa ---D---UWEV
>
> for said address PDI is 0x1E and PTI is 0x180,
>
> I used PDI to move to the exact page table, i,e, C001E000 and converted
> 0x180 index to bytes and reached the address C001E600.
>
> But in doing this I did not need to use the page directory at all i.e. I
> did not need to route through C0300000. I verified that PDE value at index
> 0x1E is 07569867 as given by !pte but what after this. what information
> this will provide, I tried looking into contents by dumping it with !dd
> 7569 but did not reach to any definite conclusion. What information this
> PFN provides?
>
> Thanks
> Aditya
>

35

Thanks for sharing!

IIRC, there is a two part series in NT Insider. And if I recall, it is
bit more elaborate than in the Windows driver book from Tony&Peter.

Also there are some good articles about this from the user level point
of view in the MSN magazine ( used to be Microsoft Journal) and all the
articles are achieved.

-pro

xxxxx@gmail.com wrote:

>> It would be nice if you could plot out what are ( if any documents) you would suggest for someone to read.
>>

I first encountered these structures in win intrnl few years back, I read it and leave it as there were some thing needs more attention than these structure’s internals(i am salaried ;-)). Few weeks back I started reading OSR’ device driver book by Mr. Peter and Mr. Tony and encountered them in more detail and felt something bugging me for more clarity. The MSDN article I got is “http://msdn.microsoft.com/en-us/library/ms810616.aspx”, its been written in 1992. Talks about basic *technical detail* and is straight on the point. It covers almost every thing about virtual memory in less than 20 pages.

Thanks,
Aditya

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

36

> I was not considering that process A’s pte will become invalid and points to the page file before

process B PTE points to PFN .

Actually, they may still point to PFN unless target pages get swapped out (they have to be inactive for quite a while in order to get swapped out). Furthermore, even if they are inactive for a while, they will be removed from the working set, but physically may still be in RAM if the system is not too low on memory - address space switch does not imply swapping pages out. The only thing address space switch implies is that target pages will be unaccesible to the CPU until page directory that describes them gets loaded into CR3…

Anton Bassov

37

@Scott

>FYI for PFNs you need to do: !dd 7569*@$pagesize Since the PFN is an index, not an address.

Mystery solved. Thank you.