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 D97E9C433F5 for ; Tue, 15 Feb 2022 21:38:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C7E16B0078; Tue, 15 Feb 2022 16:38:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 375996B007B; Tue, 15 Feb 2022 16:38:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 216656B007D; Tue, 15 Feb 2022 16:38:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0219.hostedemail.com [216.40.44.219]) by kanga.kvack.org (Postfix) with ESMTP id 12CF26B0078 for ; Tue, 15 Feb 2022 16:38:25 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A89B68249980 for ; Tue, 15 Feb 2022 21:38:24 +0000 (UTC) X-FDA: 79146328128.06.B957232 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) by imf29.hostedemail.com (Postfix) with ESMTP id 3B79B12000C for ; Tue, 15 Feb 2022 21:38:24 +0000 (UTC) Received: by mail-qk1-f182.google.com with SMTP id c189so18561573qkg.11 for ; Tue, 15 Feb 2022 13:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=J1afD2UuA2twxlw8ZzYufWhFKO6wr/3kutM+ZjyetLk=; b=Wcl7oY9fxL+v3oPFd1xJprCDBFPC/SUL0s385FIv9KvKn7xQn+INxXiqJqW1x8EuFK 7F3FLwEtLULlwb0dFj1iPOckU4U+s4WbW5s2R5XHL24xywKiiuJ50feMlNcrr3xKzU80 4ckWEYm2nGOh3ZFkrH/7ajWwCHGBfW6v4bdyJLj/PLx6TMItmI6xrQ64wW6XEWUtLkV+ xoValrFu7CWuxwnvIC3AGYTuWz9HTpBrk2HvxgS/7CEbc67DYyznj9+agowFE6ShYp9R yURG3NrplLpz7e9vOZ90uF6zp9+zUhUeGBb81PjGwmUk4HJKYJ3zsddSR9OVYYC1Awu3 P5wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=J1afD2UuA2twxlw8ZzYufWhFKO6wr/3kutM+ZjyetLk=; b=MrH1Z8Zb5algxf2Uv0U2VquZ12Rckiv0mv+OYu48NC6WR7jsPLwF2NhP4qBXrdNk+X vHQSFyd9S9L8ka9LtfF/5Q+g5INdnsz4ebP4ggV+uNj/uMWlooqZfLIK0B7WRjL72C3X tzuyEf6D3wKg4t/C65oR9+66bttEeAX1g5e4Ph3ThD2AR4ge7zjYyUGDdu4dCWpdX+gx y4FZVKhkmQU0RV7eCpgt+uu7Fh1msLdawi45jjunHe4cAaQZcJUm0nwEJMy8gxWbEB58 N+mr2Y8vU0lHjWRdj1ounQNUpspQ2Qp0kzgraR7Jz/aXr857jWn6+9/pTHVFbTH3XQ53 T8fA== X-Gm-Message-State: AOAM533wjZ/IosnD9wbYLYwgNRdpKtoh4CrYDKrURXcBUErlRKnnZP32 CQPX0CtZ1vXrqk0s1H0lcLslqg== X-Google-Smtp-Source: ABdhPJwSnmcbyCFnLifXS/yn/JrFTpEWFiC13xTSxk+iFYmllr+zSaMVP3leFQFjySBg2IBVEq4+gA== X-Received: by 2002:ae9:ddc1:: with SMTP id r184mr607603qkf.549.1644961103396; Tue, 15 Feb 2022 13:38:23 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id o81sm427231qke.134.2022.02.15.13.38.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Feb 2022 13:38:22 -0800 (PST) Date: Tue, 15 Feb 2022 13:38:20 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Matthew Wilcox cc: Hugh Dickins , 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() In-Reply-To: Message-ID: <3c6097a7-df8c-f39c-36e8-8b5410e76c8a@google.com> 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 X-Rspamd-Queue-Id: 3B79B12000C X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Wcl7oY9f; spf=pass (imf29.hostedemail.com: domain of hughd@google.com designates 209.85.222.182 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: 64haccbcuekfzf7ywt9zko95jq5btsem X-Rspamd-Server: rspam11 X-HE-Tag: 1644961104-874193 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 Tue, 15 Feb 2022, Matthew Wilcox wrote: > 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? I think you're asking the wrong question here, but perhaps you've already decided there's only one satisfactory answer to the right question. To answer what you've asked: it doesn't matter at all how you count them in mlock_count, just so long as they are counted up and down consistently. Since it's simplest just to count 1 in mlock_count for each pmd or pte, I prefer that (as I did with THPs); but if you prefer to count pmds up and down by HUGE_PMD_NR, that works too. Though, reading again, you're asking about a PMD mapping of an order-4 page? I don't understand how that could be allowed (except on some non-x86 architecture where the page table fits only 16 pages). The question I thought you should be asking is about how to count them in Mlocked. That's tough; but I take it for granted that you would not want per-subpage flags and counts involved (or not unless forced to do so by some regression that turns out to matter). And I think the only satisfactory answer is to count the whole compound_nr() as Mlocked when any part of it (a single pte, a series of ptes, a pmd) is mlocked; and (try to) move folio to Unevictable whenever any part of it is mlocked. That differs from what Kirill decided for THPs (which I cannot confidently describe, but something like count pmd as Mlocked, don't count ptes as Mlocked, but uncount pmd if any ptes), and what I simplified it to in the mm/munlock series (count pmd as Mlocked, ignore ptes), and will tend to show larger numbers for Mlocked than before; but alternatives seem unworkable to me. Hugh