[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180702133953.GV19043@dhcp22.suse.cz>
Date: Mon, 2 Jul 2018 15:39:53 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Yang Shi <yang.shi@...ux.alibaba.com>
Cc: willy@...radead.org, ldufour@...ux.vnet.ibm.com,
akpm@...ux-foundation.org, peterz@...radead.org, mingo@...hat.com,
acme@...nel.org, alexander.shishkin@...ux.intel.com,
jolsa@...hat.com, namhyung@...nel.org, tglx@...utronix.de,
hpa@...or.com, linux-mm@...ck.org, x86@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC v3 PATCH 0/5] mm: zap pages with read mmap_sem in munmap
for large mapping
On Sat 30-06-18 06:39:40, Yang Shi wrote:
>
> Background:
> Recently, when we ran some vm scalability tests on machines with large memory,
> we ran into a couple of mmap_sem scalability issues when unmapping large memory
> space, please refer to https://lkml.org/lkml/2017/12/14/733 and
> https://lkml.org/lkml/2018/2/20/576.
>
>
> History:
> Then akpm suggested to unmap large mapping section by section and drop mmap_sem
> at a time to mitigate it (see https://lkml.org/lkml/2018/3/6/784).
>
> V1 patch series was submitted to the mailing list per Andrew’s suggestion
> (see https://lkml.org/lkml/2018/3/20/786). Then I received a lot great feedback
> and suggestions.
>
> Then this topic was discussed on LSFMM summit 2018. In the summit, Michal Hock
> suggested (also in the v1 patches review) to try "two phases" approach. Zapping
> pages with read mmap_sem, then doing via cleanup with write mmap_sem (for
> discussion detail, see https://lwn.net/Articles/753269/)
The cover letter should really describe your approach to the problem.
But there is none here.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists