2024년 10월 9일 (수) 오전 3:50, SeongJae Park <sj@xxxxxxxxxx>님이 작성: > > Hello Minwoo, > > On Fri, 2 Aug 2024 00:05:46 +0000 Minwoo Jo <chminoo@xxxxxxxxxxxx> wrote: > > > Signed-off-by: Minwoo Jo <chminoo@xxxxxxxxxxxx> > > > > 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 > > [...] I apologize for the late response to your message. Based on my limited understanding, the LRU manipulation in DAMON appears to assist LRU by tracking data access to identify Hot Pages and Cold Pages, subsequently lowering the priority of Cold Pages. Additionally, this approach goes beyond simply measuring frequency, as it analyzes patterns, which I believe could lead to greater performance. By appropriately utilizing the lru_prio and lru_deprio mechanisms of DAMON's LRU_SORT, I think it could also be implemented in MGLRU. While HitShield differs from DAMON_LRU_SORT in that it checks counters during internal operations rather than monitoring the internals, I believe that by appropriately modifying this approach, we could implement the HitShield mechanism without altering the folio's internal structure or using flags. Thank you for your insights; I will definitely consider them. Thank you. Minwoo, Jo
