Can't understand Belady's anomaly - operating-system

So Belady's Anomaly states that when using a FIFO page replacement policy, when adding more page space we'll have more page faults.
My intuition says that we should less or at most, the same number of page faults as we add more page space.
If we think of a FIFO queue as a pipe, adding more page space is like making the pipe bigger:
____
O____O size 4
________
O________O size 8
So, why would you get more page faults? My intuition says that with a longer pipe, you'd take a bit longer to start having page faults (so, with an infinite pipe you'd have no page faults) and then you'd have just as many page faults and just as often as with a smaller pipe.
What is wrong with my reasoning?

The reason that when using FIFO, increasing the number of pages can increase the fault rate in some access patterns, is because when you have more pages, recently requested pages can remain at the bottom of the FIFO queue longer.
Consider the third time that "3" is requested in the wikipedia example here:
http://en.wikipedia.org/wiki/Belady%27s_anomaly
Page faults are marked with an "f".
1:
Page Requests 3 2 1 0 3 2 4 3 2 1 0 4
Newest Page 3f 2f 1f 0f 3f 2f 4f 4 4 1f 0f 0
3 2 1 0 3 2 2 2 4 1 1
Oldest Page 3 2 1 0 3 3 3 2 4 4
2:
Page Requests 3 2 1 0 3 2 4 3 2 1 0 4
Newest Page 3f 2f 1f 0f 0 0 4f 3f 2f 1f 0f 4f
3 2 1 1 1 0 4 3 2 1 0
3 2 2 2 1 0 4 3 2 1
Oldest Page 3 3 3 2 1 0 4 3 2
In the first example (with fewer pages), there are 9 page faults.
In the second example (with more pages), there are 10 page faults.
When using FIFO, increasing the size of the cache changes the order in which items are removed. Which in some cases, can increase the fault rate.
Belady's Anomaly does not state anything about the general trend of fault rates with respect to cache size. So your reasoning (about viewing the cache as a pipe), in the general case is not wrong.
In summary:
Belady's Anomaly points out that it is possible to exploit the fact that larger cache sizes can cause items in the cache to be raised in the FIFO queue later than smaller cache sizes, in order to cause larger cache sizes to have a higher fault rate under a particular (and possibly rare) access pattern.

This statement is wrong because it is overgeneralized:
Belady's Anomaly states that when using a FIFO page replacement policy, when adding more page space we'll have more page faults
This is a corrected version:
"Belady's Anomaly states that when using a FIFO page replacement policy, when adding more page space, some memory access patterns will actually result in more page faults."
In other words... whether the anomaly is observed depends on the actual memory access pattern.

Belady's anomaly occurs in page replacement algorithm do not follow stack algorithm.That is the pages when frames were less should be a subset of pages when frame are more.On increasing page frame,the page frames which were present before has to be there.This can occur in FIFO sometimes,even random page replacement but not LRU or optimal.

I could not understand belady anomaly even after reading the Wikipedia article and accepted answer. After writing the trace I kind of got it. Here I’d like to share my understanding.
Keys to understanding belady anomaly.
Unlike LRU, FIFO just pushes out the oldest elements regardless of
frequency. So staying in FIFO longer means falling victim to
eviction.
From here, I refer to 3 and 4 pages FIFO queue as FIFO3 and FIFO4.
To understand Wikipedia example, I divided it into 2 parts. When FIFO3 catches up with FIFO4 and when FIFO3 overtakes FIFO4.
How FIFO3 catch up with FIFO4 on 9th
Look at 3 in both FIFOs. In FIFO3, 3 is evicted on 4th and came back on 5th. So it was still there on 8th and cache hit happened.
In FIFO4, 3 is HIT on 5th, but this cache hit made 3 stays longer and evicted on 7th, right before next 3 on 8th.
2 is the same as 3. Second 2(6th) is MISS on FIFO3 and HIT on FIFO4, but third 2(9th) is HIT on FIFO3, and MISS on FIFO4.
It might help to think like this. On FIFO3, 3 was updated on 5th so stayed longer until 8th. On FIFO4 3 was old and evicted on 7th, right before next 3 comes.
How FIFO3 overtakes FIFO4
Because there are 2 cache misses on 8, 9th for FIFO4, 4 is pushed down and evicted on 11th in FIFO4.
FIFO3 still retains 4 on 12th because there are cache hit on 8, 9th, so 4 was not pushed down.
I think this is why Wikipedia's aritcle says "Penny Wise, Pound Foolish"
Conclusion
FIFO is a simple and naive algorithm that does not take frequency into account.
You might get a better understanding by applying LRU(Least Recently Used) to Wikipedia’s example. In LRU, 4 is better than 3.

Belady's anomaly happens in a FIFO scheme only when the page that is currently being referred is the page that was removed last from the main memory. only in this case even though you increase more page space, you'll have more page faults.

Related

Paging--What happens when page tables do not fit perfectly in a page in Multilevel Paging?

In a 3-level paging system, when every page size is 512 bytes and an entry size is 4 bytes, we can know that every single page has 128 entries. So we can design 7 bits (log128) of the VPN(Virtual Page Number) as an index in the third level page table, which makes the page table fit perfectly in a page. What happens if we just design 6 bits as an index? I think on third level page table, some pages could not be correctly "transfer" to corresponding physical frame number because their page number can not be represented by a six-digit index. For example, when the OS "cut" the whole page table into 3 parts, each of which has 128 entries, and one entry happens to be the 100th entry of second part. How can we use 6 digits to index into 100 to get the right frame number in physical address? Or the "cut" process is smart enough to put just 64 entries and waste another 64 entries in every page? Or we actually can use 8 digits to index into 128 entries table, using just 7 digits and ignore one digit? This problem really confuses me a lot because even if the third level page table perfectly fits into one page, the first and the second level page table sometimes do not fit perfectly at all.
I got the answer from Stack Exchange and here is the same question https://cs.stackexchange.com/questions/103454/what-does-it-mean-the-outer-level-page-table-need-not-be-page-aligned.

How to calculate which virtual logical address corresponds to physical address?

Assume that the page table for the process currently running on the processor looks as shown in the figure below. All numbers are decimal, all numbers starting with 0 and all addresses are memory syllable addresses. The page size is 1024 bytes.
Which physical address (if any) does each of the following logical (virtual) addresses correspond to? Indicates if a page error occurs while translating the title.
Which physical address (if any) does each of the following logical (virtual) addresses correspond to? Indicates if a page error occurs while translating the title.
a) 1085
b) 2321
c) 5409
number of pages
valid/invalid bit
number of frames
0
1
4
1
1
7
2
0
-
3
1
2
4
0
-
5
1
0
I don't want the solution for this problem, I want someone to explain how this kind of problems are solved.
I think you can guess most configuration from the question. I'll take a) as an example. Maybe you can tell me if I get the answer right and then you can solve the rest by yourself?
The first step is to determine what is the part of the virtual address representing the offset in the page table, and the part representing the offset in the physical frame. For address 1085 and page size of 1024 bytes, you need 10 bits for the offset in the physical frame and the rest for the offset in the page table.
1085 decimal = 0x43D = 0b100 0011 1101
The ten least significant bits (to the right) are the offset in the physical frame. That is 0b00 0011 1101 = 0x3D = 61 decimal. So now you know that the offset in the physical frame will be 61 bytes.
To calculate in what page this offset will be, you take the leftover bits (to the left). That is 0b1 = 0x1 = 1 decimal. This references page table entry 1. Page table entry 1 has the valid bit set. It means that the page is present in memory and will not cause a page fault. The page table entry points to frame number 7. There are 7 frames before frame 7: frames 0, 1, 2, 3, 4, 5, and 6. Thus this virtual address should translate to 7 * 1024 + 61 = 7229.

SCAN and CSCAN algorithm

I am having hard time understanding the working of SCAN and CSCAN algorithm of disk scheduling.I understood FCFS,Closest Cylinder Next but heard that SCAN resembles elevator mechanism and got confused.
My book says that for the incoming order :[10 22 20 2 40 6 38] (while the disk currently at 20) the SCAN moving at the start serves [(20) 20 22 38 40 10 6 2]; this requires moves of [0 2 16 2 30 4 4] cylinders, a total of 58 cylinders.
How does the pattern [(20) 20 22 38 40 10 6 2] came?
Let's know what the SCAN(Elevator) disk-scheduling algorithm says:-
It scans down towards the nearest end and then when it hits the bottom
it scans up servicing the requests that it didn't get going down. If a
request comes in after it has been scanned it will not be serviced
until the process comes back down or moves back up.
So, in your case, the current position of disk is at 20. So, as per the SCAN algorithm, it'll scan towards the nearest end, and just after hitting bottom, it scans up servicing the requests back up.
The order is :-
| |
| * current position | * move back up to upside
|---> nearest disk is this one |
| so it'll move down and so on. |
| as it hit the bottom _______
____
Fig :- Demonstration of SCAN algorithm
So, as per the given data, the order will be [(20) 20 22 38 40 10 6 2];
EDIT :-
The only difference between SCAN and CSCAN is that in CSCAN,
it begins its scan toward the nearest end and works it way all the way
to the end of the system. Once it hits the bottom or top it jumps to
the other end and moves in the same direction,unlike the SCAN which
moves back to upside using the same path.
As per CSCAN,the direction of movement would be same uptil bottom and then it'll reverse the path.
So, as per the given data, the order will be [(20) 20 22 38 40 2 6 10]; Notice the change in last three disk positions.
I hope it is clear. Feel free to ask remaining doubts.

Number of page table index bits in multilevel paging

A processor uses 36 bit physical addresses and 32 bit virtual addresses with a page frame size of 4 KBytes. Each page table entry size is of 4 bytes. A three level page table is used for virtual to physical address translation, where the virtual address is used as follows :
bits 30 - 31 are used to index into the first level page table
bits 21 - 29 are used to index into the second level page table
bits 12 - 20 are used to index into the third level page table
bits 0 - 11 are used as offset within the page
The number of bits required for addressing the next level page table ( or page frame ) in the page table entry of the first , second and third level page tables are respectively ?
This was a question asked in GATE 2008.
My Analysis: The maximum number of page frames = (physical address size) / ( page size ) = 2^36 / 2^12 = 2^24.
Thus, 24 bits will be enough to index the page numbers in the 3rd level page table. Now we have to find out how many page tables will be there in the 3rd level. Its given that 9 bits are used to index into the 3rd level page tables. So there are 2^9 page tables in level 3. That means 2^32 virtual space is contained in 2^9 page tables so entries per page table= 2^32/2^9 = 2^23. So 23 bits are required in an l2 page table entry to index the entries of a particular page table in 3rd level page table. 2^9 page tables are there in L2 from L1 page table we need to get to any one of these 2^9 page tables. So 9 bits are required in L1.
This analysis somehow doesn't seem right. I am very much confused. Can someone please explain the concepts ?
At first we have physical address of 2^36, and page size is 2^12. Hence 2^24 should be the number of pages. and you figured that right.
Since given 9 bits for 3rd level page table, ie 2^9 and then 4 bytes per entry, so 2^11. Now 2^36/2^11 would give 2^25. Hence 25 bits (25 bits at second level table).
Now again given 9 bits for second level page table. so the same logic applies again
2^36/2^11, which again is 2^25.(25 bits at first level table).
hence the answer must be
25,25,24
One thing that you have to understand is, that though virtual address space is 2^32, we need to map the entire 2^36 entries and not 2^32.Also, each page can take care of 2^9 * 2^2, and you didn't consider this 2^2 as well. The same thing holds at the higher level as well
You should have a look at this question
and this wikipedia entry, especially the figure.
In this question, there are 36 bits of physical memory, out of which 12 bits are designated for the offset. The offset is not going to change in any level (since it is the size of the page). Therefore in any level there will be 24 frame bits required for the page table. Since there are 36 bits of physical memory, you cannot increase the physical memory size by increasing the number of bits in the page table.

How to calculate page frames in a 16 bit address pointer

I'm looking over some exam papers for Operating Systems and I have come across a question which I simply cannot figure out. The memory management scheme is paging
Here is the question:
An operating system that runs on a CPU with a 16 bit address pointer employs a paging memory management scheme with a page size of 1024 bytes.
a) At most how many frames can physical memory contain?
b) Indicate which bits in an address pointer are used for page and offset.
c) A process image of size 3.5K resides in memory. You are given the page table of this process in Figure 1 below. What physical address will the hexadecimal logical address 0x0FCE result in? Show your calculations.
d) How much internal fragmentation does this process produce?
Page Frame
0 4
1 8
2 9
3 6
Figure 1 Process Page Table
Can anybody help me with this ?
A 16bit address bus allows to access 2^16 = 64kB of physical memory. Since on this system you have pages of size 1024B = 2^10, your memory falls into 2^16 / 2^10 = 2^6 physical frames.
Given the previous result, with pages of 1024 = 2^10 bytes, you need 10 bits for accessing any bytes of the page. Thus, the 6 high-order bits ares used for getting the page index from the page table (basically the figure 1 in your homework), and the 10 low-order bits are used for offsetting in that page.
The logical address 0xfce resides in the fourth page because the six high-order bits are 000011b = 3 = 4th page = 0x0c00-0x0fff. Given the page table and assuming the physical memory is sequential, the fourth page maps to the sixth physical frame which start at 1024 * 6 = 0x1800 = 0001100000000000b. The six high-order bits of the page are 000110b, where we add the 10 bits of offset resulting from the previous answer: 000110b << 10 | 0x3ce = 0x1bce.
Since the frame allocation is not sequential (4, 6, 8, 9), the hole between pages 4 and 6 (i.e. 1024B), and the hole between page 6 and 8(i.e. again 1024B), result in physical memory fragmentation.
Hope this help.