[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180620071708.GI13685@dhcp22.suse.cz>
Date: Wed, 20 Jun 2018 09:17:08 +0200
From: Michal Hocko <mhocko@...nel.org>
To: Yang Shi <yang.shi@...ux.alibaba.com>
Cc: Peter Zijlstra <peterz@...radead.org>, willy@...radead.org,
ldufour@...ux.vnet.ibm.com, akpm@...ux-foundation.org,
mingo@...hat.com, acme@...nel.org,
alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
namhyung@...nel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 PATCH 2/2] mm: mmap: zap pages with read mmap_sem for
large mapping
On Tue 19-06-18 14:13:05, Yang Shi wrote:
>
>
> On 6/19/18 3:02 AM, Peter Zijlstra wrote:
[...]
> > Hold up, two things: you having to copy most of do_munmap() didn't seem
> > to suggest a helper function? And second, since when are we allowed to
>
> Yes, they will be extracted into a helper function in the next version.
>
> May bad, I don't think it is allowed. We could reform this to:
>
> acquire write mmap_sem
> vma lookup (split vmas)
> release write mmap_sem
>
> acquire read mmap_sem
> zap pages
> release read mmap_sem
>
> I'm supposed this is safe as what Michal said before.
I didn't get to read your patches carefully yet but I am wondering why
do you need to split in the first place. Why cannot you simply unmap the
range (madvise(DONTNEED)) under the read lock and then take the lock for
write to finish the rest?
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists