[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fd5c7272f19442828fb00dff7cb24fae@AcuMS.aculab.com>
Date: Thu, 22 Mar 2018 16:36:14 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Laurent Dufour' <ldufour@...ux.vnet.ibm.com>,
Matthew Wilcox <willy@...radead.org>,
Yang Shi <yang.shi@...ux.alibaba.com>
CC: Michal Hocko <mhocko@...nel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 1/8] mm: mmap: unmap large mapping by section
From: Laurent Dufour
> Sent: 22 March 2018 16:29
...
> This being said, having a per VMA lock could lead to tricky dead lock case,
> when merging multiple VMA happens in parallel since multiple VMA will have to
> be locked at the same time, grabbing those lock in a fine order will be required.
You could have a global lock and per VMA locks.
Anything that only accesses one VMA could release the global lock after
acquiring the per VMA lock.
If code needs multiple VMA 'locked' it can lock and unlock each VMA
in turn, then keep the global lock held.
David
Powered by blists - more mailing lists