page fault

[George2]

Hello everyone,


I can understand hard page fault is we need to load from page file into working set (RAM). But what is a soft page fault? I am confused.


thanks in advance,
George

[Boris K K]

Wikipedia
Microsoft TechNet

Edit: I forgot to add the most important link

[George2]

Thanks Boris,


I have read the 1st link before. And I am confused what means "but its status is not updated as 'present' in hardware, then it is called a minor or soft page fault". Any ideas?

For the 2nd TechNet link, it only contains information about hard page fault -- no soft page fault -- which is the most confusing to me. :-)

Wikipedia
Microsoft TechNet

Edit: I forgot to add the most important link

regards,
George

[Boris K K]

I suppose by "hardware" they actually mean the page table of the process where the page fault occurs.
- the process does not "know" where in physical memory to look for the requested page
- the page is already present in the physical memory (loaded by another process or for another reason)
- it is sufficient to update the page table so that the process can access the requested page

The second link does mention soft page faults and how they differ from hard ones in the section Number of Hard Page Faults.

[George2]

Sorry for my limited knowledge about this topic, Boris!

1.

I am confused about the logics you mentioned,

--------------------
- the process does not "know" where in physical memory to look for the requested page
- the page is already present in the physical memory (loaded by another process or for another reason)
--------------------

2.

From your reply, I think there should be two related memory management data structures, one is used for system wide to see which page is loaded, and process local data structure for the current process to management page?

If the current process does not know where to look for the requested page from physical memory, how could the process know the page is already loaded in physical memory?

I suppose by "hardware" they actually mean the page table of the process where the page fault occurs.
- the process does not "know" where in physical memory to look for the requested page
- the page is already present in the physical memory (loaded by another process or for another reason)
- it is sufficient to update the page table so that the process can access the requested page

The second link does mention soft page faults and how they differ from hard ones in the section Number of Hard Page Faults.

regards,
George

[Boris K K]

It is not the process, it is the operating system kernel handling the page fault that knows. Suppose two processes map the same file in memory in modes compatible with each other, for example both read-only. Each process receives a pointer to its view of the file. This pointer is only valid within the process. When the corresponding process is running, the CPU uses the page table associated with this process to convert logical addresses (pointers used inside the program) to physical addresses (the ones on CPU-memory bus). If there is no rule (page table entry) for a specific address, a page fault occurs. Now it is responsibility of the operating system to check if the program has the right to access this specific address and what it expects to find there. In the case of file mapping the OS will find out that the region program 1 is trying to read from is associated with a specific offset inside a particular file. If this part of the file has already been read in the memory by another process, the OS can simply update the page table of the first process to point to the same physical location in computer RAM where the needed data is already present and resume the execution of process 1.

It is a page fault - the execution of program 1 is interrupted and the OS has to intervene.

If it does not require the data to be read from an external storage (disk), then it can be handled much more quickly and is called a soft page fault.

[George2]

Thanks Boris!


Great! I understand the soft page fault in the situation in the situation of file map.

Here is a link I found which is more comprehensive of the possible 3 situations of when there is soft page fault.

http://blogs.msdn.com/greggm/archive.../21/61237.aspx

Beyond the case of file map, there are two additional cases when soft page fault happens,

1. this can happen with pages that the program wants to be zero (called ‘demand zero’ pages)
2. when a page is written to for the first time (‘copy on write’ pages)

Do you understand what does (1) and (2) mean?

It is not the process, it is the operating system kernel handling the page fault that knows. Suppose two processes map the same file in memory in modes compatible with each other, for example both read-only. Each process receives a pointer to its view of the file. This pointer is only valid within the process. When the corresponding process is running, the CPU uses the page table associated with this process to convert logical addresses (pointers used inside the program) to physical addresses (the ones on CPU-memory bus). If there is no rule (page table entry) for a specific address, a page fault occurs. Now it is responsibility of the operating system to check if the program has the right to access this specific address and what it expects to find there. In the case of file mapping the OS will find out that the region program 1 is trying to read from is associated with a specific offset inside a particular file. If this part of the file has already been read in the memory by another process, the OS can simply update the page table of the first process to point to the same physical location in computer RAM where the needed data is already present and resume the execution of process 1.

It is a page fault - the execution of program 1 is interrupted and the OS has to intervene.

If it does not require the data to be read from an external storage (disk), then it can be handled much more quickly and is called a soft page fault.

regards,
George

[Boris K K]

Although this also applies to other cases, I will continue with examples from file mapping:

(1) If you do

HANDLE hMapping = CreateFileMapping(INVALID_HANDLE_VALUE, ..., PAGE_READWRITE, ...);
LPVOID pBase = MapViewOfFile(hMapping, FILE_MAP_ALL_ACCESS, ...)

you get a region of memory not associated with a particular file, which is guaranteed to be initially filled with zeroes. The operating system need not provide all this memory immediately. The first time you try to read or write to a specific address, a page fault occurs, then the OS allocates a new physical page, zeroes it, and updates the page table of your process.

(2) In case of

HANDLE hMapping = CreateFileMapping(hFile, ..., PAGE_WRITECOPY, ...);
LPVOID pBase = MapViewOfFile(hMapping, FILE_MAP_COPY, ...)

you can modify the mapped file data without actually modifying file's content. Suppose you first read from a mapped address and this causes a soft or hard page fault depending on whether the data was available in memory or must be read from the disk. If the mode is copy-on-write, the OS will update the page table but will mark the page as read-only. Now if you try to write to it, another page fault occurs, this time because you are attempting an operation not permitted for read-only pages. Then OS will allocate another physical memory page no longer associated with the mapped file, copy the page you are trying to modify there, and update your page table with read/write access to the new location of the page. Essentially, for each page you try to modify you get your very own clone you can do whatever you like to.

As you can see, in both (1) and (2) there are page faults but they can be resolved without accessing external storage as

(1) The initial content of the page is known - all zeroes.
(2) The initial content of the page is copied from another memory page.

[George2]

Thanks Boris,


Your reply is great! I have made some self-study as well. There is a situation which we missed when there is soft page fault, which is not included in any case we mentioned before.

Do you agree? Any comments about my new findings? :-)

This new case is mentioned here,

http://support.microsoft.com/kb/108449/en-us

--------------------
Process pages that are paged out of your process space are moved into the "standby list," where they remain until sufficient free RAM is available, or until system memory is low and they need to be reused. If these pages are accessed by your process while they are still on the standby list and more RAM has become available, they will be "soft-faulted" back into the working set. This does not require any disk access, so it is very quick. Therefore, even though you have an upper limit to the size of your working set, you can still have quite a few process pages in memory that can be pulled back into your working set very quickly.
--------------------

Although this also applies to other cases, I will continue with examples from file mapping:

(1) If you do

HANDLE hMapping = CreateFileMapping(INVALID_HANDLE_VALUE, ..., PAGE_READWRITE, ...);
LPVOID pBase = MapViewOfFile(hMapping, FILE_MAP_ALL_ACCESS, ...)

you get a region of memory not associated with a particular file, which is guaranteed to be initially filled with zeroes. The operating system need not provide all this memory immediately. The first time you try to read or write to a specific address, a page fault occurs, then the OS allocates a new physical page, zeroes it, and updates the page table of your process.

(2) In case of

HANDLE hMapping = CreateFileMapping(hFile, ..., PAGE_WRITECOPY, ...);
LPVOID pBase = MapViewOfFile(hMapping, FILE_MAP_COPY, ...)

you can modify the mapped file data without actually modifying file's content. Suppose you first read from a mapped address and this causes a soft or hard page fault depending on whether the data was available in memory or must be read from the disk. If the mode is copy-on-write, the OS will update the page table but will mark the page as read-only. Now if you try to write to it, another page fault occurs, this time because you are attempting an operation not permitted for read-only pages. Then OS will allocate another physical memory page no longer associated with the mapped file, copy the page you are trying to modify there, and update your page table with read/write access to the new location of the page. Essentially, for each page you try to modify you get your very own clone you can do whatever you like to.

As you can see, in both (1) and (2) there are page faults but they can be resolved without accessing external storage as

(1) The initial content of the page is known - all zeroes.
(2) The initial content of the page is copied from another memory page.

regards,
George