Great. After watching several videos and reading several papers about page replacement algorithms, this is first touching the problem how pages are marked as accessed in CPU and stating that real world implementations are approximations. No one mentioned how horrible idea is to maintain true LRU in multithreaded environment (not in OS, but application that processes data than can easily exceed memory capacity) However video does not mention how often to run the clock and if to run them through the whole circle (very often, when memory is nearly full, once per second, at adaptive rate....) I guess that real OSes has/had this mechanism for active pages and data are going to inactive FIFO before going to swap file or being freed and it uses some combination of this and 2Q. I see problem with this algorithm itself - when there is either very little activity or all the activity is performed over small amount of pages (e.g. computations), nearly whole memory is marked as inactive very soon and information if page was used 2 seconds ago or 30 minutes ago is lost.
Excellent video! So I guess the guarantee of clock algorithm is merely that the evicted hasn't been accessed since the last eviction. The time interval between the last and current eviction is the minimal guarantee. For the same reason, it is not an exact approximation. Empirically one may extend the time length of the guarantee by replacing "the time interval between the last and current eviction" by "the time interval between the n-th back eviction and the current eviction". Finally, one caveat is that there is always going to be a page that is going to be evicted, since if there is no page that hasn't be used between the last and current (impending) eviction, then the clock algorithm manually creates a new eviction cycle so that there in the most newly created eviction cycle, there exists a page that has used bit = 0 (in fact, all of the pages).
suuuuper entertaining teacher and she says is clear as glass. Nice example also! Saved me a day before exam haha
Very helpful video, now I fully understand how clock algorithm works!
Thank you for this straight and concise explanation!
Very brief and on to the point. Congratulations!
The powerpoint demonstration is so explicit, thx!!!
Great explanation! the demonstration was really helpful. Thanks for sharing the knowledge :)
Excellent Video and explanation . Thank you for uploading such a wonderful lecture
great lecture presentation; thanks much
Thank you for this explanation. Clear and understandable.
Amazing. It really cleared out all of my doubts.
Thank you very much
Excellent presentation. Thank you ma'am
Thank you so much for the explaination, it was very clear.
Excellent explanation
2mins starting at 5:20 and everything is clearly explained!
Precise and understandable explanation, thank you!
Great. After watching several videos and reading several papers about page replacement algorithms, this is first touching the problem how pages are marked as accessed in CPU and stating that real world implementations are approximations. No one mentioned how horrible idea is to maintain true LRU in multithreaded environment (not in OS, but application that processes data than can easily exceed memory capacity)
However video does not mention how often to run the clock and if to run them through the whole circle (very often, when memory is nearly full, once per second, at adaptive rate....)
I guess that real OSes has/had this mechanism for active pages and data are going to inactive FIFO before going to swap file or being freed and it uses some combination of this and 2Q.
I see problem with this algorithm itself - when there is either very little activity or all the activity is performed over small amount of pages (e.g. computations), nearly whole memory is marked as inactive very soon and information if page was used 2 seconds ago or 30 minutes ago is lost.
Thank you, for this most wonderful clarification.
Phenomenal explanation!
Great explanation! Thank you!
Great explanation, thanks
amazing explanation
Excellent video! So I guess the guarantee of clock algorithm is merely that the evicted hasn't been accessed since the last eviction. The time interval between the last and current eviction is the minimal guarantee. For the same reason, it is not an exact approximation. Empirically one may extend the time length of the guarantee by replacing "the time interval between the last and current eviction" by "the time interval between the n-th back eviction and the current eviction". Finally, one caveat is that there is always going to be a page that is going to be evicted, since if there is no page that hasn't be used between the last and current (impending) eviction, then the clock algorithm manually creates a new eviction cycle so that there in the most newly created eviction cycle, there exists a page that has used bit = 0 (in fact, all of the pages).
Thank you :) You've been a great help.
Thanks
Do you have any code we can look at?