Re: [PATCH] Hitshield : Something new eviction process for MGLRU

[SeongJae Park <sj@kernel.org>]

Hello Minwoo,

On Fri, 2 Aug 2024 00:05:46 +0000 Minwoo Jo <chminoo@g.cbnu.ac.kr> wrote:

> Signed-off-by: Minwoo Jo <chminoo@g.cbnu.ac.kr>
> 
> This commit addresses the page space occupancy issue that arose
> in the previous commit with the HitShield technology.
> 
> The HitShield technology is based on the observation that MGLRU
> does not take into account the state of the folio during eviction.
> 
> I assumed that if a folio, which has been updated only 1 to 3 times,
> has increased in generation until the point of eviction,
> it is likely to be referenced less in the future.

So, my humble understanding of the point is that, you want to improve the
kernel's reclamation logic by making it awares not only recency, but also
frequency?

Given existence of several previous frequency based page placement algorithm
optimization researches including LRFU, CAR and CART, I think the overall idea
might make sense at least in some use cases.  I'm not sure whether the
threshold value and the mechanism to measure the frequency make sense and/or
can be applied to general cases, though.

> 
> Therefore, I implemented this technology to protect frequently updated folios.
> 
> I added the hitshield_0, hitshield_1, and hitshield flags to the page flag.
> 
> Upon my review, I confirmed that the flags occupy positions 0 to 28.
> 
> Thus, I believe that allocating 3 flags, or 3 bits, is sufficient.

As others also mentioned, I think even three bits could be challinging to add.

In my humble opinion, frequency monitoring could be done using data structures
and access check mechanisms other than folio/LRU and reclamation logic.  Then,
the monitoring mechanism could manipulate LRU lists based on the frequency
data.  Modifying reclamation code to refer to the frequency data could also be
another way.

DAMON_LRU_SORT [1,2] could be an example of such approaches (driven by the
monitoring mechanism without reclamation code modification).  Of course,
DAMON_LRU_SORT would have many limitations and rooms for improvements.  I'm
curious if you also had a time to consider that kind of approaches?  If you did
so but found some critical problems and resulted in this patch, it would be
great if you can further share the found problems.

[1] https://lwn.net/Articles/905370/
[2] https://www.kernel.org/doc/html/latest/admin-guide/mm/damon/lru_sort.html


Thanks,
SJ

[...]