Re: Page replacement algorithm in buffer cache

 >If we
> use the value calculated locally to decide on eviction, the highly
> used buffers where this is likely will get at least one clock sweep
> cycle of grace time. If they are indeed highly used it's likely that
> someone will manage to bump the usage_count in the meanwhile. If they
> are not hot, a rare speedup or delay in eviction won't matter much.

Yeah, a buffer page getting an extra clock sweep life in lieu of
potential performance improvement isn't much of a cost to pay.

So, essentially, we decide locally which page to evict, then try to
get a lock on the header only when we want to evict the victim page?
Sounds like the contention for the header should go down considerably.

Unlocked incrementing/decrementing of USAGE_COUNT may lead to the
values of USAGE_COUNT differing from the actual value they should be
having by 1 or 2 counts in case of high contention buffer pages, which
shouldn't matter, as they are in high contention. I agree, it is
likely that a process(s) will increase the usage_count anyways.

> Getting rid of memory barriers associated with locking in the clock
> sweep will pipeline the loads and stores and so should bring on a good
> performance increase for scanning large swathes of buffer headers.
>
This does sound interesting. If the Jenkins based performance farm
gets ready, we can do some tests and see the kind of results we get.

Regards,

Atri



--
Regards,

Atri
l'apprenant