lkml.org 
[lkml]   [2020]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v8 03/10] mm/lru: replace pgdat lru_lock with lruvec lock
From
Date


在 2020/4/15 下午9:42, Alex Shi 写道:
> Hi Johannes,
>
> Thanks a lot for point out!
>
> Charging in __read_swap_cache_async would ask for 3 layers function arguments
> pass, that would be a bit ugly. Compare to this, could we move out the
> lru_cache add after commit_charge, like ksm copied pages?
>
> That give a bit extra non lru list time, but the page just only be used only
> after add_anon_rmap setting. Could it cause troubles?

Hi Johannes & Andrew,

Doing lru_cache_add_anon during swapin_readahead can give a very short timing
for possible page reclaiming for these few pages.

If we delay these few pages lru adding till after the vm_fault target page
get memcg charging(mem_cgroup_commit_charge) and activate, we could skip the
mem_cgroup_try_charge/commit_charge/cancel_charge process in __read_swap_cache_async().
But the cost is maximum SWAP_RA_ORDER_CEILING number pages on each cpu miss
page reclaiming in a short time. On the other hand, save the target vm_fault
page from reclaiming before activate it during that time.

Judging the lose and gain, and the example of shmem/ksm copied pages, I believe
it's fine to delay lru list adding till activate the target swapin page.

Any comments are appreciated!

Thanks
Alex


>
> I tried to track down the reason of lru_cache_add here, but no explanation
> till first git kernel commit.
>
> Thanks
> Alex
>

\
 
 \ /
  Last update: 2020-04-16 10:04    [W:0.089 / U:0.672 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site