[PATCH] mm/vmscan: call vmpressure_prio() in kswapd reclaim path

[PATCH] mm/vmscan: call vmpressure_prio() in kswapd reclaim path

[Yafang Shao]

Once the reclaim scanning depth goes too deep, it always mean we are
under memory pressure now.
This behavior should be captured by vmpressure_prio(), which should run
every time when the vmscan's reclaiming priority (scanning depth)
changes.
It's possible the scanning depth goes deep in kswapd reclaim path,
so vmpressure_prio() should be called in this path.

Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
---
 mm/vmscan.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index b79f584..1fbd3be 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3609,8 +3609,11 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int classzone_idx)
 		if (nr_boost_reclaim && !nr_reclaimed)
 			break;
 
-		if (raise_priority || !nr_reclaimed)
+		if (raise_priority || !nr_reclaimed) {
+			vmpressure_prio(sc.gfp_mask, sc.target_mem_cgroup,
+					sc.priority);
 			sc.priority--;
+		}
 	} while (sc.priority >= 1);
 
 	if (!sc.nr_reclaimed)
-- 
1.8.3.1

Re: [PATCH] mm/vmscan: call vmpressure_prio() in kswapd reclaim path

[Andrew Morton]

On Mon, 10 Jun 2019 16:42:27 +0800 Yafang Shao <laoar.shao@gmail.com> wrote:

> Once the reclaim scanning depth goes too deep, it always mean we are
> under memory pressure now.
> This behavior should be captured by vmpressure_prio(), which should run
> every time when the vmscan's reclaiming priority (scanning depth)
> changes.
> It's possible the scanning depth goes deep in kswapd reclaim path,
> so vmpressure_prio() should be called in this path.
> 
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>

What effect does this change have upon userspace?

Presumably you observed some behaviour(?) and that behaviour was
undesirable(?) and the patch changed that behaviour to something
else(?) and this new behaviour is better for some reason(?).

Re: [PATCH] mm/vmscan: call vmpressure_prio() in kswapd reclaim path

[Yafang Shao]

On Tue, Jun 11, 2019 at 5:12 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 10 Jun 2019 16:42:27 +0800 Yafang Shao <laoar.shao@gmail.com> wrote:
>
> > Once the reclaim scanning depth goes too deep, it always mean we are
> > under memory pressure now.
> > This behavior should be captured by vmpressure_prio(), which should run
> > every time when the vmscan's reclaiming priority (scanning depth)
> > changes.
> > It's possible the scanning depth goes deep in kswapd reclaim path,
> > so vmpressure_prio() should be called in this path.
> >
> > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
>
> What effect does this change have upon userspace?
>
> Presumably you observed some behaviour(?) and that behaviour was
> undesirable(?) and the patch changed that behaviour to something
> else(?) and this new behaviour is better for some reason(?).
>

When there're few free memory,
the usespace can receive the critical memory pressure event earlier,
because when we try to do direct reclaim we always wakeup the kswapd first.
Currently the vmpressure work (vmpressure_work_fn) can only be
scheduled in direct reclaim path,
and with this change, the vmpressure work can be scheduled in kswapd
reclaim path.

I think receiving the critical memory pressure event earlier can give
the userspace more chance to do something to prevent random OOM.

With this change, the vmpressure work will be scheduled more frequent
than before when the system is under memory pressure.

Thanks
Yafang