lkml.org 
[lkml]   [2019]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RESEND PATCH 1/2 -mm] mm: account lazy free pages separately
On Fri 09-08-19 07:57:44, Yang Shi wrote:
> When doing partial unmap to THP, the pages in the affected range would
> be considered to be reclaimable when memory pressure comes in. And,
> such pages would be put on deferred split queue and get minus from the
> memory statistics (i.e. /proc/meminfo).
>
> For example, when doing THP split test, /proc/meminfo would show:
>
> Before put on lazy free list:
> MemTotal: 45288336 kB
> MemFree: 43281376 kB
> MemAvailable: 43254048 kB
> ...
> Active(anon): 1096296 kB
> Inactive(anon): 8372 kB
> ...
> AnonPages: 1096264 kB
> ...
> AnonHugePages: 1056768 kB
>
> After put on lazy free list:
> MemTotal: 45288336 kB
> MemFree: 43282612 kB
> MemAvailable: 43255284 kB
> ...
> Active(anon): 1094228 kB
> Inactive(anon): 8372 kB
> ...
> AnonPages: 49668 kB
> ...
> AnonHugePages: 10240 kB
>
> The THPs confusingly look disappeared although they are still on LRU if
> you are not familair the tricks done by kernel.

Is this a fallout of the recent deferred freeing work?

> Accounted the lazy free pages to NR_LAZYFREE, and show them in meminfo
> and other places. With the change the /proc/meminfo would look like:
> Before put on lazy free list:

The name is really confusing because I have thought of MADV_FREE immediately.

> +LazyFreePages: Cleanly freeable pages under memory pressure (i.e. deferred
> + split THP).

What does that mean actually? I have hard time imagine what cleanly
freeable pages mean.
--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2019-08-09 10:33    [W:0.080 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site