On Tue, Apr 2, 2013 at 9:24 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> One thought I had for fiddling with usage_count is to make it grow
> additively (x = x + 1) and decay exponentially (x = x >> 1). I'm not
> sure the idea is any good, but one problem with the current system is
> that it's pretty trivial for a buffer to accumulate five touches, and
> after that we lose all memory of what the frequency of access is, so a
> pages of varying different levels of "hotness" can all have usage
> count 5. This might allow a little more refinement without letting
> the time to degrade the usage count get out of control.
This is just off the top of my head, but one possible solution could
be to quantize the levels of hotness. Specifically, we could
categorize buffers based on hotness. All buffers start in level 1 and
usage_count 0. Whichever buffer reaches usage_count of 5, and next
clock sweep which wants to increment its usage_count(hence taking it
above 5) sees that, it promotes the buffer to the next level, and
resets its usage_count to 0. Same logic applies for each level. When
we decrement usage_count and see that it is zero(for some buffer), if
it is in a level > 1, we demote the buffer to the next lower level. If
the buffer is in level 1, it is a potential candidate for replacement.
This will allow us to have a loose idea about the hotness of a page,
without actually storing the usage_count for a buffer. We can still
update usage_count without locking, as buffers in high contention
which miss an update in their usage_count wont be affected by that
missed update, in accordance with all the discussion upthread.
Thoughts/Comments?
Regards,
Atri
--
Regards,
Atri
l'apprenant
