[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <af218b46-ece3-1189-e43c-209ec5cf1022@oracle.com>
Date: Fri, 10 May 2019 15:45:04 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Larry Bassel <larry.bassel@...cle.com>,
Matthew Wilcox <willy@...radead.org>
Cc: dan.j.williams@...el.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-nvdimm@...ts.01.org
Subject: Re: [PATCH, RFC 2/2] Implement sharing/unsharing of PMDs for FS/DAX
On 5/10/19 9:16 AM, Larry Bassel wrote:
> On 09 May 19 09:49, Matthew Wilcox wrote:
>> On Thu, May 09, 2019 at 09:05:33AM -0700, Larry Bassel wrote:
>>> This is based on (but somewhat different from) what hugetlbfs
>>> does to share/unshare page tables.
>>
>> Wow, that worked out far more cleanly than I was expecting to see.
>
> Yes, I was pleasantly surprised. As I've mentioned already, I
> think this is at least partially due to the nature of DAX.
I have not looked in detail to make sure this is indeed all the places you
need to hook and special case for sharing/unsharing. Since this scheme is
somewhat like that used for hugetlb, I just wanted to point out some nasty
bugs related to hugetlb PMD sharing that were fixed last year.
5e41540c8a0f hugetlbfs: fix kernel BUG at fs/hugetlbfs/inode.c:444!
dff11abe280b hugetlb: take PMD sharing into account when flushing tlb/caches
017b1660df89 mm: migration: fix migration of huge PMD shared pages
The common issue in these is that when unmapping a page with a shared PMD
mapping you need to flush the entire shared range and not just the unmapped
page. The above changes were hugetlb specific. I do not know if any of
this applies in the case of DAX.
--
Mike Kravetz
Powered by blists - more mailing lists