在 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.
