Re: [PATCH 0/2] Support kshrinkd

From: 李培锋
Date: Mon Feb 19 2024 - 23:14:26 EST



在 2024/2/20 10:55, Matthew Wilcox 写道:
On Tue, Feb 20, 2024 at 10:04:33AM +0800, 李培锋 wrote:
Monkey-test in phone with 16G-ram for 300 hours shows that almost one-third

of the contended-pages can be freed successfully next time, putting back
those

folios to LRU's head would break the rules of inative-LRU.
You talk about "the rules of inactive LRU" like we care. The LRU is
an approximation at best. What are the *consequences*?
Is there a
benchmark that executes more operations per second as a result of
this patch?

Hi Sir:

1. For the above data in 300 hours test in 16G-ram device:

- 795503 folios would be passed during shrink_folio_list since lock contended;

- 262577 folios would be reclaimed successfully but putback in head of inative-lru.


2. Converted to per second,:

- 0.243 folios would be putback in the head of inative-lru mistakenly


3. issues:

There are two issues with the current situation:

1. some cold-pages would not be freed in time, like the date we got in 16GB-devices almost 1GB-folios

would not be freed in time during the test, which would cause shrink_folio_list to become inefficient.

Especially for some folios, which are very cold and correspond to a common virtual memory space,

we had found some cases that more than 20 folios were contended in rmap_walk and putback

in the head of inactive-LRU during one shrink_folio_list proccess(isolate 32 folios) and more background

user-process was killed by lmkd. Kshrinkd would let reclaim-path more efficient, and reduce 2% lmkd rate.


2. another issue is that staying more cold folios at the head of inative-lru would result in some hot-pages

to be reclaimed, and more file-refault and anon-swapin. Data would be updated soon if need.