> 7 апр. 2021 г., в 08:59, Thomas Munro <thomas.mu...@gmail.com> написал(а):
>
> The remaining thing that bothers me about this patch set is that there is
> still a linear search in the replacement algorithm, and it runs with an
> exclusive lock. That creates a serious problem for large caches that still
> aren't large enough. I wonder if we can do something to improve that
> situation in the time we have. I considered a bunch of ideas but could only
> find one that fits with slru.c's simplistic locking while tracking recency.
> What do you think about a hybrid of SLRU and random replacement, that retains
> some characteristics of both? You could think of it as being a bit like the
> tournament selection of the genetic algorithm, with a tournament size of
> (say) 8 or 16. Any ideas on how to evaluate this and choose the number? See
> attached.
> <v15-0001-Add-a-buffer-mapping-table-for-SLRUs.patch><v15-0002-Make-all-SLRU-buffer-sizes-configurable.patch><v15-0003-Use-hybrid-random-SLRU-replacement-for-SLRUs.patch>
Maybe instead of fully associative cache with random replacement we could use
1-associative cache?
i.e. each page can reside only in one spcific buffer slot. If there's something
else - evict it.
I think this would be as efficient as RR cache. And it's soooo fast.
Best regards, Andrey Borodin.
