1

As title.

There is a buffer pool with 3 pages that receives requests for the following page numbers:

2,4,4,2,5,2,1,1,3,1

The replacement policies are MRU and CLOCK. I am confused about how they work. Could someone show me? Thanks a lot~

update:

There is my solution following the MRU policy:

2

2 4

2 4

2 4

2 4 5

2 4 5

1 4 5

3 4 5

1 4 5

Is that right?

And following the LRU policies:

          hit/miss?

2 m

2 4 m

2 4 h

2 4 h

2 4 5 m

2 4 5 h

2 1 5 m

2 1 5 h

2 1 3 m

2 1 3 h

Is that right?

Echo0831
  • 307
  • 2
  • 5
  • 14

2 Answers2

1

For MRU eviction policy, let's keep the MRU page at the front. With the given request list, following will be the state of buffers:

2 -> 2
4 -> 2 4
4 -> 2 4
2 -> 4 2
5 -> 4 2 5
2 -> 4 5 2
1 -> 4 5 1
1 -> 4 5 1
3 -> 4 5 3
1 -> 4 5 1

For the CLOCK eviction policy, the page list would be ( * represents the buffer location to be filled in when a page fault occurs):

2 -> 2 *
4 -> 2 4 *
4 -> 2 4 *
2 -> 2 4 *
5 -> 2* 4 5
2 -> 2* 4 5
1 -> 1 4* 5
1 -> 1 4* 5
3 -> 1 3 5*
1 -> 1 3 5*

Following LRU policy, let's keep LRU page at the back. State of buffers will be:

2 -> 2
4 -> 2 4
4 -> 2 4
2 -> 4 2
5 -> 4 2 5
2 -> 4 5 2
1 -> 5 2 1
1 -> 5 2 1
3 -> 2 1 3
1 -> 2 3 1
displayName
  • 13,888
  • 8
  • 60
  • 75
  • 1
    @Am_I_Helpful: The order will change in memory? No. The order will change in the data structure being used to know which page was most recently used? Yes. LinkedHashMaps are used to build time dependent caches. So when policy is MRU, items move to the top of the list when they are accessed and that is what I'm demonstrating. – displayName Feb 25 '16 at 05:40
  • Ok, I agree with your point. But, I answered it in the manner humans would understand. – Am_I_Helpful Feb 25 '16 at 05:44
  • @Am_I_Helpful: You may have... but I didn't have any problem at all with your answer. Only clarified what you thought was wrong with mine. :) – displayName Feb 25 '16 at 05:48
1

There is my solution following the MRU policy... Is that right?

As per the definition of MRU mentioned by you, your MRU page replacement policy appears correct.

The replacement policies are MRU and CLOCK. I am confused about how they work. In this case(for 2,4,4,2,5,2,1,1,3,1 page numbers) :

In Clock page replacement policy, the OS circulates through pages, clearing reference bits and finding a page with reference bit set to 0.

Page number                  Reference bit

 2                               1
2,4                             1,1
2,4                             1,1
2,4                             1,1
2,4,5                          1,1,1
2,4,5                          1,1,1
1,4,5                          1,0,0
1,4,5                          1,0,0
1,3,5                          1,1,0
1,3,5                          1,1,0

And following the LRU policies: hit/miss? Is that right?

YES, for the LRU page replacement, the page ordering as well as the number of hits and misses both are correct.

Am_I_Helpful
  • 18,735
  • 7
  • 49
  • 73
  • The requests should be 2 4 4 2 5 2 1 1 3 1. SO sorry about the typo! – Echo0831 Feb 25 '16 at 05:43
  • @mihuecho - NO problem , I have revised the answer. Not much edit was required :D – Am_I_Helpful Feb 25 '16 at 05:46
  • Thank you very much! Can I ask one more question about that? How to calculate the hit rate of them? I mean, the hit rate is the hits/all requests(here the number is 10). I am so confused about whether a page is missed or hit one? If a page is first requested, then it's a missed one. If we request it again, then it should be a hit one? – Echo0831 Feb 25 '16 at 05:55
  • @mihuecho - Ok, you may. But, do remember that this question is getting too broad to answer as one. – Am_I_Helpful Feb 25 '16 at 05:57
  • @mihuecho - yes, the hit/miss rate is just the count of times they were available/unavailable in the memory such that the page fault was prevented/occurred. ***If a page is first requested, then it's a missed one. If we request it again ,then only if it is present in the memory, then it should be a hit one.*** – Am_I_Helpful Feb 25 '16 at 06:15