On Friday, March 22, 2013 4:16 PM Atri Sharma wrote:
> >
> >> I think that if the initialization of USAGE_COUNT starts at the
> maximum
> >> allowed value instead of one, we can have a better solution to this
> >> problem.
> >
> > So what is your idea, if you start at maximum, what we will do for
> further
> > accesses to it?
>
> I havent chalked out a detailed plan yet, but I think the idea of
> initializing USAGE_COUNT to maximum value is not at all good. I was
> just thinking off the top of my head.
>
> > Why do you want to give more priority to just loaded page?
>
> I just want it to have more chances to stay, rather than being
> replaced pretty early. This is because, as I said earlier, a new page
> could be in high demand in near future, which would lead to repeated
> replacement-bringing in of page and hence cause overheads.
>
>
>
>
> >> Another,more complex solution could be to introduce an aging factor
>
> This is the one I think would work out best, add an age factor as to
> the time duration which an entry has spent in the cache along with its
> usage count.
>
> So, what I am proposing here is to add another factor in the
> clocksweep algorithm when it selects victim pages for replacement.
> Specifically, the selection of victim pages should be done with the
> usage_count AND the time spent by the entry in the cache. This would
> give priority to pages with high accesses and not ignore relatively
> young pages as well. If a page is not accessed for a long time after
> it was allocated, it would be the ideal victim for replacement both in
> terms of USAGE_COUNT as well as age.
What would you do if the only young page has usage count zero during second
sweep.
I don't think introducing another factor along with usage count would do any
much help.
Have you encountered any such workload very relatively young pages are
getting victimized
and the same is causing performance issues?
With Regards,
Amit Kapila.