Messages in this thread | | | Date | Thu, 18 Feb 2016 14:41:44 +0200 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv2 17/28] thp: skip file huge pmd on copy_huge_pmd() |
| |
On Tue, Feb 16, 2016 at 07:46:37AM -0800, Dave Hansen wrote: > 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?
Yep.
> 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?
Sure.
-- Kirill A. Shutemov
| |