From: lipeifeng <lipeifeng@oppo.com>

'commit 6d4675e60135 ("mm: don't be stuck to rmap lock on reclaim path")'
The above patch would avoid reclaim path to stuck rmap lock.
But it would cause some folios in LRU not sorted by aging because
the contended-folios in rmap_walk would be putbacked to the head of LRU
during shrink_folio_list even if the folios are very cold.

The patchset setups new kthread:kshrinkd to reclaim the contended-folio
in rmap_walk when shrink_folio_list, to avoid to break the rules of LRU.

lipeifeng (2):
  mm/rmap: support folio_referenced to control if try_lock in rmap_walk
  mm: support kshrinkd

 include/linux/mmzone.h        |   6 ++
 include/linux/rmap.h          |   5 +-
 include/linux/swap.h          |   3 +
 include/linux/vm_event_item.h |   2 +
 mm/memory_hotplug.c           |   2 +
 mm/rmap.c                     |   5 +-
 mm/vmscan.c                   | 205 ++++++++++++++++++++++++++++++++++++++++--
 mm/vmstat.c                   |   2 +
 8 files changed, 221 insertions(+), 9 deletions(-)

-- 
2.7.4

add experts from Linux and Google.


在 2024/2/19 22:17, lipeifeng@oppo.com 写道:
> From: lipeifeng <lipeifeng@oppo.com>
>
> 'commit 6d4675e60135 ("mm: don't be stuck to rmap lock on reclaim path")'
> The above patch would avoid reclaim path to stuck rmap lock.
> But it would cause some folios in LRU not sorted by aging because
> the contended-folios in rmap_walk would be putbacked to the head of LRU
> during shrink_folio_list even if the folios are very cold.
>
> The patchset setups new kthread:kshrinkd to reclaim the contended-folio
> in rmap_walk when shrink_folio_list, to avoid to break the rules of LRU.
>
> lipeifeng (2):
>    mm/rmap: support folio_referenced to control if try_lock in rmap_walk
>    mm: support kshrinkd
>
>   include/linux/mmzone.h        |   6 ++
>   include/linux/rmap.h          |   5 +-
>   include/linux/swap.h          |   3 +
>   include/linux/vm_event_item.h |   2 +
>   mm/memory_hotplug.c           |   2 +
>   mm/rmap.c                     |   5 +-
>   mm/vmscan.c                   | 205 ++++++++++++++++++++++++++++++++++++++++--
>   mm/vmstat.c                   |   2 +
>   8 files changed, 221 insertions(+), 9 deletions(-)
>

On Mon, Feb 19, 2024 at 10:17:01PM +0800, lipeifeng@oppo.com wrote:
> 'commit 6d4675e60135 ("mm: don't be stuck to rmap lock on reclaim path")'
> The above patch would avoid reclaim path to stuck rmap lock.
> But it would cause some folios in LRU not sorted by aging because
> the contended-folios in rmap_walk would be putbacked to the head of LRU
> during shrink_folio_list even if the folios are very cold.
> 
> The patchset setups new kthread:kshrinkd to reclaim the contended-folio
> in rmap_walk when shrink_folio_list, to avoid to break the rules of LRU.

Patch 1/2 didn't make it to my inbox or to lore.  But you should talk
about the real world consequences of this in the cover letter.  What do
we observe if this problem happens?  How much extra performance will we
gain by applying this patch?

在 2024/2/20 0:51, Matthew Wilcox 写道:
> On Mon, Feb 19, 2024 at 10:17:01PM +0800, lipeifeng@oppo.com wrote:
>> 'commit 6d4675e60135 ("mm: don't be stuck to rmap lock on reclaim path")'
>> The above patch would avoid reclaim path to stuck rmap lock.
>> But it would cause some folios in LRU not sorted by aging because
>> the contended-folios in rmap_walk would be putbacked to the head of LRU
>> during shrink_folio_list even if the folios are very cold.
>>
>> The patchset setups new kthread:kshrinkd to reclaim the contended-folio
>> in rmap_walk when shrink_folio_list, to avoid to break the rules of LRU.
> Patch 1/2 didn't make it to my inbox or to lore.
Hi Sir, I had resent to you.
>   But you should talk
> about the real world consequences of this in the cover letter.  What do
> we observe if this problem happens?  How much extra performance will we
> gain by applying this patch?

Hi Sir:

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.

- pgsteal_kshrinkd 262577
- pgscan_kshrinkd 795503


"pgsteal_kshrinkd" means that the amount of those contended-folios which 
can be

freed successfully but be putbacked in the head of inactive-LRU, more 
than 1GB(262577 folios).

Mobile-phone with 16-ram, the total amount of inactive are around 4.5G, 
so that the

contended-folios would break the rules of inactive-LRU.

- nr_inactive_anon 1020953
- nr_inactive_file 204801


Actually, The patchset had been merged in Google kernel/common since

android12-5.10 and android13-5.15, and were taken in more than 100 millions

android-phone devices more than 1.5 years.

But for the reason of GKI, the patches were implemented in the form of 
hooks,

the patches merged in google-line as follows:

https://android-review.googlesource.com/c/kernel/common/+/2163904

https://android-review.googlesource.com/c/kernel/common/+/2191343

https://android-review.googlesource.com/c/kernel/common/+/2550490

https://android-review.googlesource.com/c/kernel/common/+/2318311

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?

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