Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4537040imm; Tue, 11 Sep 2018 13:31:44 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYZ8h57kLlATOclqdt56fKgT+TEG5nVrENA8pbLs8sW0WNWfNVpf2mBHHMT63LSVnIHqrMW X-Received: by 2002:a62:858c:: with SMTP id m12-v6mr31458037pfk.173.1536697904068; Tue, 11 Sep 2018 13:31:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536697904; cv=none; d=google.com; s=arc-20160816; b=YrXpAnwOkltEbu2jxIE21zLC6A97LVjqSpqMfw7YIbgsf8xSkCoQ1+1pQrO067Fo74 2rtYk5PJAmeAndAtezf76l7Y192zsDjKqJ7kIt7PCtgWNHNRfIWc9cQSjgM91iZPbV1O dcxjTXRsqhEdpCu/ZaDYIQElHIpDhD2ndLzF2lDoMAbxctdMTACaqfW1zfeEM1Bvlukk fFcDWEXo/gIyJz4JRIPDKnz3IUfgz67TdQU+YRpweNDlaTho3TfDihZzgpRFjMmQ0Q6D wu439Nc/AhobgNDFpfEAmoqJb8c/s8sFy354BJQsYKmyHKr3dgpbthxD8lS5V2+97994 nZHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from; bh=ZOiOVW+WRXQQPvJ2AXAeozLyu+i/hMzyvRG++JH6Tv0=; b=xHfpaw2zmty1MJo9JrPpCIb22dgVW9qLV3Qy9/AejYNZj35Jmhf16Gp9yTCwC/wWVZ 16aS9f7SV6po0qWv0jtlkyu8oPigmy9GcWuzqR8eKWiGNy8JuVXGhoXHQkKxHJEXRscV Etved9M9vrPJyZWxwXcq5cDV1vsQwXSQt2gJnkzsRhFqEpGZAA3q7FkwCQ4b+lq/HauC E9dV8hd4yLydsbNSZxGeg/eJKmLzpcdzmuW04dwDcwDhsumj2+QwvN86ICT8r5RUPeKf xiOOU07Ww1UlQofCflsmKV5rKT9qOfzTi8uwZ5lzXEUZkK8UqLv79EskH94yQlszRPj1 ofZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b87-v6si22424280pfm.5.2018.09.11.13.30.59; Tue, 11 Sep 2018 13:31:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727790AbeILBbF (ORCPT + 99 others); Tue, 11 Sep 2018 21:31:05 -0400 Received: from mail-qk1-f193.google.com ([209.85.222.193]:38746 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726919AbeILBbE (ORCPT ); Tue, 11 Sep 2018 21:31:04 -0400 Received: by mail-qk1-f193.google.com with SMTP id g197-v6so17673019qke.5 for ; Tue, 11 Sep 2018 13:30:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=ZOiOVW+WRXQQPvJ2AXAeozLyu+i/hMzyvRG++JH6Tv0=; b=LfCL1ujyKm3yjxE5avb3KA/vI9p+SNdzjk5L0Tnxw5GkgTrk3L4nyhTmttjQ6Q0muj b/bi7wnYLL5f9aq12baH9sO7mE5T2W16x8H56mI0kplVaTgysDrcyFwbohCHqdtRaUO4 e/cX6gXqFHBtJaqjQpa0tUfHWEd/XoK+2yXavbtG6oaytDDn//HWvXS6+xhmSJYUXVEl fTR93wORJJWdxyuVj8n2fhGlYpPUNJpLe5lg4xnmEpLekP8h/QUgbD75PrPhY11hAO7E R6sOndV92ejInI9K0EMfYBL3UGV6RJ1sc3OpI2KDDX5xWDuXASuf7eSbKPBIMoGLPy/c xuJA== X-Gm-Message-State: APzg51Drv33ovO8S30qRQ7LTO8QcyNX2Im939Ml1lHi3KzGECmAhZgfP oYwic487/bvLNrOMcdMLBcGc/Q== X-Received: by 2002:a37:642:: with SMTP id 63-v6mr19849206qkg.11.1536697805167; Tue, 11 Sep 2018 13:30:05 -0700 (PDT) Received: from [192.168.1.153] (pool-108-53-39-217.nwrknj.fios.verizon.net. [108.53.39.217]) by smtp.gmail.com with ESMTPSA id q18-v6sm11756531qtk.57.2018.09.11.13.30.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 13:30:03 -0700 (PDT) From: "Zi Yan" To: "Kirill A. Shutemov" Cc: "Andrew Morton" , "Vegard Nossum" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, "Naoya Horiguchi" , "Vlastimil Babka" , "Andrea Arcangeli" Subject: Re: [PATCH] mm, thp: Fix mlocking THP page with migration enabled Date: Tue, 11 Sep 2018 16:30:02 -0400 X-Mailer: MailMate (1.12r5523) Message-ID: <5E196C27-3D56-4D76-B361-0665CB3790BF@cs.rutgers.edu> In-Reply-To: <20180911103403.38086-1-kirill.shutemov@linux.intel.com> References: <20180911103403.38086-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_F56E6C2A-13C4-4D7A-96AB-E3BCB22C8184_="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_F56E6C2A-13C4-4D7A-96AB-E3BCB22C8184_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Kirill, On 11 Sep 2018, at 6:34, Kirill A. Shutemov wrote: > A transparent huge page is represented by a single entry on an LRU list= =2E > Therefore, we can only make unevictable an entire compound page, not > individual subpages. > > If a user tries to mlock() part of a huge page, we want the rest of the= > page to be reclaimable. > > We handle this by keeping PTE-mapped huge pages on normal LRU lists: th= e > PMD on border of VM_LOCKED VMA will be split into PTE table. > > Introduction of THP migration breaks the rules around mlocking THP > pages. If we had a single PMD mapping of the page in mlocked VMA, the > page will get mlocked, regardless of PTE mappings of the page. > > For tmpfs/shmem it's easy to fix by checking PageDoubleMap() in > remove_migration_pmd(). > > Anon THP pages can only be shared between processes via fork(). Mlocked= > page can only be shared if parent mlocked it before forking, otherwise > CoW will be triggered on mlock(). > > For Anon-THP, we can fix the issue by munlocking the page on removing P= TE > migration entry for the page. PTEs for the page will always come after > mlocked PMD: rmap walks VMAs from oldest to newest. > > Test-case: > > #include > #include > #include > #include > #include > > int main(void) > { > unsigned long nodemask =3D 4; > void *addr; > > addr =3D mmap((void *)0x20000000UL, 2UL << 20, PROT_READ | PROT_WRITE= , > MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, -1, 0); > > if (fork()) { > wait(NULL); > return 0; > } > > mlock(addr, 4UL << 10); > mbind(addr, 2UL << 20, MPOL_PREFERRED | MPOL_F_RELATIVE_NODES,= > &nodemask, 4, MPOL_MF_MOVE | MPOL_MF_MOVE_ALL); > > return 0; > } > > Signed-off-by: Kirill A. Shutemov > Reported-by: Vegard Nossum > Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path") > Cc: [v4.14+] > Cc: Zi Yan > Cc: Naoya Horiguchi > Cc: Vlastimil Babka > Cc: Andrea Arcangeli > --- > mm/huge_memory.c | 2 +- > mm/migrate.c | 3 +++ > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 533f9b00147d..00704060b7f7 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2931,7 +2931,7 @@ void remove_migration_pmd(struct page_vma_mapped_= walk *pvmw, struct page *new) > else > page_add_file_rmap(new, true); > set_pmd_at(mm, mmun_start, pvmw->pmd, pmde); > - if (vma->vm_flags & VM_LOCKED) > + if ((vma->vm_flags & VM_LOCKED) && !PageDoubleMap(new)) > mlock_vma_page(new); > update_mmu_cache_pmd(vma, address, pvmw->pmd); > } > diff --git a/mm/migrate.c b/mm/migrate.c > index d6a2e89b086a..01dad96b25b5 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -275,6 +275,9 @@ static bool remove_migration_pte(struct page *page,= struct vm_area_struct *vma, > if (vma->vm_flags & VM_LOCKED && !PageTransCompound(new)) > mlock_vma_page(new); > > + if (PageTransCompound(new) && PageMlocked(page)) > + clear_page_mlock(page); > + > /* No need to invalidate - it was non-present before */ > update_mmu_cache(vma, pvmw.address, pvmw.pte); > } > -- = > 2.18.0 Thanks for your patch. It fixes the mlock problem demonstrated by your te= st program. I want to understand the Anon THP part of the problem more clearly. For A= non THPs, you said, PTEs for the page will always come after mlocked PMD. I just wo= nder that if a process forks a child1 which forks its own child2 and the child1 mlocks= a subpage causing split_pmd_page() and migrates its PTE-mapped THP, will the kernel see the= sequence of PMD-mapped THP, PTE-mapped THP, and PMD-mapped THP while walking VMAs? Will the second PM= D-mapped THP reset the mlock on the page? In addition, I also discover that PageDoubleMap is not set for double map= ped Anon THPs after migration, the following patch fixes it. Do you want me to send it separately or you= can merge it with your patch? diff --git a/mm/rmap.c b/mm/rmap.c index eb477809a5c0..defe8fc265e3 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1121,6 +1121,16 @@ void do_page_add_anon_rmap(struct page *page, */ if (compound) __inc_node_page_state(page, NR_ANON_THPS); + else { + if (PageTransCompound(page) && compound_mapcount(= page) > 0) { + struct page *head =3D compound_head(page)= ; + int i; + + SetPageDoubleMap(head); + for (i =3D 0; i < HPAGE_PMD_NR; i++) + atomic_inc(&head[i]._mapcount); + } + } __mod_node_page_state(page_pgdat(page), NR_ANON_MAPPED, n= r); } if (unlikely(PageKsm(page))) =E2=80=94 Best Regards, Yan Zi --=_MailMate_F56E6C2A-13C4-4D7A-96AB-E3BCB22C8184_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQFKBAEBCgA0FiEEOXBxLIohamfZUwd5QYsvEZxOpswFAluYJcoWHHppLnlhbkBj cy5ydXRnZXJzLmVkdQAKCRBBiy8RnE6mzBKSB/9rtfp7XzaFZe4W1J/lzjPZvoy2 xisHmr4+5FNTaEfdiev9t4e/TYtpHr/1IgCtn59dzwXUtQnsEFF0fWLvGqTgJP5/ 6KULctGIlJfzHTBxWckD4Jz7aqFuRe9L2abMqr2zlegAdpDsGQGLKZhm7oQ7Pq+Q 1MVM6GNizdJfyRpIrdaq3pfrYk0emj07K6d+WwGR+VKSbiMMIDWK/GqPwOL8pCCv zFpl6aTeZKda5TS4nXsF5pHCrVb4Ig2Cpgeoo5AiKOFTSxlhf7oDHUK4SG96TQxe XgX33CllJX7kKRxpMvJEorH/tCAXxWVqE7KCj0XYpeJr7mhd4CK/njSpK4wn =9ZTQ -----END PGP SIGNATURE----- --=_MailMate_F56E6C2A-13C4-4D7A-96AB-E3BCB22C8184_=--