[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56C3445D.3040305@intel.com>
Date: Tue, 16 Feb 2016 07:46:37 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Hugh Dickins <hughd@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Christoph Lameter <cl@...two.org>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
Jerome Marchand <jmarchan@...hat.com>,
Yang Shi <yang.shi@...aro.org>,
Sasha Levin <sasha.levin@...cle.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCHv2 17/28] thp: skip file huge pmd on copy_huge_pmd()
On 02/16/2016 02:14 AM, Kirill A. Shutemov wrote:
> On Fri, Feb 12, 2016 at 10:42:09AM -0800, Dave Hansen wrote:
>> On 02/11/2016 06:21 AM, Kirill A. Shutemov wrote:
>>> File pmds can be safely skip on copy_huge_pmd(), we can re-fault them
>>> later. COW for file mappings handled on pte level.
>>
>> Is this different from 4k pages? I figured we might skip copying
>> file-backed ptes on fork, but I couldn't find the code.
>
> Currently, we only filter out on per-VMA basis. See first comment in
> copy_page_range().
>
> Here we handle PMD mapped file pages in COW mapping. File THP can be
> mapped into COW mapping as result of read page fault.
OK... So, copy_page_range() has a check for "Don't copy ptes where a
page fault will fill them correctly." Seems sane enough, but the check
is implemented using a check for the VMA having !vma->anon_vma, which is
a head-scratcher for a moment. Why does that apply to huge tmpfs?
Ahh, MAP_PRIVATE. MAP_PRIVATE vmas have ->anon_vma because they have
essentially-anonymous pages for when they do a COW, so they don't hit
that check and they go through the copy_*() functions, including
copy_huge_pmd().
We don't handle 2M COW operations yet so we simply decline to copy these
pages. Might cost us page faults down the road, but it makes things
easier to implement for now.
Did I get that right?
Any chance we could get a bit of that into the patch descriptions so
that the next hapless reviewer can spend their time looking at your code
instead of relearning the fork() handling for MAP_PRIVATE?
Powered by blists - more mailing lists