From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C76C4C433F5 for ; Tue, 15 Feb 2022 15:22:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 259526B0078; Tue, 15 Feb 2022 10:22:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2083C6B007B; Tue, 15 Feb 2022 10:22:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AA2A6B007D; Tue, 15 Feb 2022 10:22:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id ECB506B0078 for ; Tue, 15 Feb 2022 10:22:40 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AB84A181AC9C6 for ; Tue, 15 Feb 2022 15:22:40 +0000 (UTC) X-FDA: 79145381280.27.702D344 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf03.hostedemail.com (Postfix) with ESMTP id C50A82000A for ; Tue, 15 Feb 2022 15:22:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=4CEufNPi0mf8HHPhcFQPBOMOzkgqFViDRsTOMQmjSo4=; b=JNIiCzymk35zUKtFR2HzYl9tZj 9RCXKtLExlprEpeih1IkSb5+dI5T8lAdB4b8Mx44AxPsy5SYOcaCWKo9BFbZiG9jDnmztNfoc5+CA 2zXllkSE5GZwZ2iA96jJxpZywgDQb1LiAyZ7MiU5MolALnSfEpFtB4xrlzgCfbBSdeXBYDApUL7GA vTMxCFCMS3Vy2TM6LlyJoXRSgXN1xACyFc15ivWf7/bSI4gkSm8PDji/AhhnOinxEGvsNesbCZieL ftoozfC885x6q+zKHMSkZOz1X5yAw9oMfumQL/KsSQxiuAp597Upw9fJMriMllDAJhxJudDoFNo2B ih0LzK9A==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJzes-00DwfC-4U; Tue, 15 Feb 2022 15:22:26 +0000 Date: Tue, 15 Feb 2022 15:22:26 +0000 From: Matthew Wilcox To: Hugh Dickins Cc: Andrew Morton , Michal Hocko , Vlastimil Babka , "Kirill A. Shutemov" , David Hildenbrand , Alistair Popple , Johannes Weiner , Rik van Riel , Suren Baghdasaryan , Yu Zhao , Greg Thelen , Shakeel Butt , Yang Li , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 04/13] mm/munlock: rmap call mlock_vma_page() munlock_vma_page() Message-ID: References: <55a49083-37f9-3766-1de9-9feea7428ac@google.com> <501673c-a5a-6c5f-ab65-38545dfb723d@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501673c-a5a-6c5f-ab65-38545dfb723d@google.com> Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=JNIiCzym; dmarc=none; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C50A82000A X-Stat-Signature: fmunyb33rar5a91g8umtictb1ei9zdob X-HE-Tag: 1644938559-140743 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 14, 2022 at 06:26:39PM -0800, Hugh Dickins wrote: > Add vma argument to mlock_vma_page() and munlock_vma_page(), make them > inline functions which check (vma->vm_flags & VM_LOCKED) before calling > mlock_page() and munlock_page() in mm/mlock.c. > > Add bool compound to mlock_vma_page() and munlock_vma_page(): this is > because we have understandable difficulty in accounting pte maps of THPs, > and if passed a PageHead page, mlock_page() and munlock_page() cannot > tell whether it's a pmd map to be counted or a pte map to be ignored. > [...] > > Mlock accounting on THPs has been hard to define, differed between anon > and file, involved PageDoubleMap in some places and not others, required > clear_page_mlock() at some points. Keep it simple now: just count the > pmds and ignore the ptes, there is no reason for ptes to undo pmd mlocks. How would you suggest we handle the accounting for folios which are intermediate in size between PMDs and PTEs? eg, an order-4 page? Would it make sense to increment mlock_count by HUGE_PMD_NR for each PMD mapping and by 1 for each PTE mapping?