linux-kernel - Re: [PATCH 0/2] Support kshrinkd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <95a87f90-f82d-f146-110e-1e23cd8d8b24@oppo.com>
Date: Tue, 20 Feb 2024 12:14:08 +0800
From: 李培锋 <lipeifeng@...o.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: akpm@...ux-foundation.org, david@...hat.com, osalvador@...e.de,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org, v-songbaohua@...o.com,
 gregkh@...gle.com, tkjos@...gle.com, surenb@...gle.com
Subject: Re: [PATCH 0/2] Support kshrinkd

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