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 00E0FC001DE for ; Tue, 18 Jul 2023 22:48:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E3866B0078; Tue, 18 Jul 2023 18:48:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 494686B007D; Tue, 18 Jul 2023 18:48:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 334CE8D0012; Tue, 18 Jul 2023 18:48:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 217C66B0078 for ; Tue, 18 Jul 2023 18:48:54 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DDCBB1A0225 for ; Tue, 18 Jul 2023 22:48:53 +0000 (UTC) X-FDA: 81026224146.30.C0C909D Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf10.hostedemail.com (Postfix) with ESMTP id 1468DC0007 for ; Tue, 18 Jul 2023 22:48:51 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=PBfU50Rl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689720532; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=64xvKcnKy5DgmAZbLYy2NqkO8PtnqPDYZ+M2QATChtA=; b=MBswZdi5wevL2q/J0KD+kZ1cT+sBmjTJUMua2iMJW3by/v7FSYVQ9rqZv9kUjukgrJ0932 LhODiKk94pOtuVPPDlao474gBSO//tK83pnN5gBVEJZiRVfWY+3ioxaPkADKGJiw5pbtHj eTrExzgvighi1FbL9gHIa5SkmEu+jlc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=PBfU50Rl; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689720532; a=rsa-sha256; cv=none; b=PaMlBDHG9RmTf9qjqUUOUHXz/0VvTN4YqMXR28PQB8LzCU7i5LskEdFKYkA3Yfj1i0S6tX zROY0jyadyFUBQxbXrsBpIh3GOCl7uYmqqU9mruBqsYFh+eMOddPByIc2CDBFQKAydBQJM vkOwz9XbRXcQyHwTDzz0inui/V0uLiQ= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2b703d7ed3aso98437761fa.1 for ; Tue, 18 Jul 2023 15:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689720530; x=1692312530; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=64xvKcnKy5DgmAZbLYy2NqkO8PtnqPDYZ+M2QATChtA=; b=PBfU50Rlso2jIontKrtUVaAwaXFFweeazhC+YKqXuXYFS8JJVQy4pVS8ehe+VQZLL4 y+slzR2h7pb6ndGjwpzFOVXGym/e2O2BvK1j7+MHYz8NnQMRgNsab0nJlEDi6mTI7Qow kyScqipk5OhjNsorAEm0VraYWQRGr/bQtyYWTUSBt/PpmF8boBNuhqFMOfZvp/TxjDAd OESLDPYtcEImtbl2qnJd1YU5bp0vHwQLrmyyePzYrGKhbo1XeLaUeQgVOMMitBFTylXA +1wcITGaYN69h3K6BkmW45xFVpqgONlOyG1IYZmuDwYa5pQwdX5DjSYuK2GIH1WkbNCo 9Xaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689720530; x=1692312530; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=64xvKcnKy5DgmAZbLYy2NqkO8PtnqPDYZ+M2QATChtA=; b=T+Qt4byeaaI5AVZE5GGH0G0dXsXIFrD7yMbMdVfSkTs9WF2FQOCKlWUgka29GwBigw vHDfLXecXF5TvZ/J9H6cPt8ahJqsPQTtW3wiRnu6xfV1G9huxvTpKm4Zi8b3Ciu2lxMl 2NLMQ2NlC0VZiHvsMA2CUb6D1onqIPYUaa1Lf9Hq3mn6TtACTj2aNLN4kiGacjuDeFfq ndT/l8HiZQVgmVFV6VbImvbvTzL0TySmhwrzVzCWA+tiHJsbvuDh8mCMbMawFz2z1gy8 r6eLzX0yXmjgfHXb650pbpGjkn5BGFfyTymC+8uTRPot8BjOBSDm4oZNc+rJKdUOB/D/ tMjw== X-Gm-Message-State: ABy/qLY7QZdA2NkCkfvmhiJSojy8bVLI1aHYsFrWS9n+5sJG/WMkL9dz lNTrslGoqYT9BEiKwl4WGI1uPl7tbSMJ6Z2OfPV9HA== X-Google-Smtp-Source: APBJJlEiO9y+TmNGlE8Dp1HF6JhU0+nm56elr0V5vduRRlStDfG8bqlc89HroNCkPTytLSHF9EkuR3DP/4FEtOlkGds= X-Received: by 2002:a2e:a410:0:b0:2b6:e13f:cfd7 with SMTP id p16-20020a2ea410000000b002b6e13fcfd7mr11793989ljn.4.1689720529870; Tue, 18 Jul 2023 15:48:49 -0700 (PDT) MIME-Version: 1.0 References: <20230712060144.3006358-1-fengwei.yin@intel.com> <20230712060144.3006358-4-fengwei.yin@intel.com> <40cbc39e-5179-c2f4-3cea-0a98395aaff1@intel.com> <16844254-7248-f557-b1eb-b8b102c877a2@intel.com> In-Reply-To: <16844254-7248-f557-b1eb-b8b102c877a2@intel.com> From: Yosry Ahmed Date: Tue, 18 Jul 2023 15:48:13 -0700 Message-ID: Subject: Re: [RFC PATCH v2 3/3] mm: mlock: update mlock_pte_range to handle large folio To: Yin Fengwei Cc: Yu Zhao , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, willy@infradead.org, david@redhat.com, ryan.roberts@arm.com, shy828301@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1468DC0007 X-Stat-Signature: 9shg89k1d4cotdetrwtr4pz9eq3h1ets X-Rspam-User: X-HE-Tag: 1689720531-177563 X-HE-Meta: U2FsdGVkX19uJTMOMuMXkglT+NYooevIANvD/eA10UJlsdH0QyvshmbMyriTqKUK2foJEozDYJC7sZ3MwqBctQGnx9dTsKrvuEdQMTbrH0vwYxYY2AzX6V4bmknqcC00zSJGxvPRC1r093i1frH/XhPtbne49ZG6LYeKER5GTJtePUisW9c0feiYCbq4eohzIEqMs4ht9xAc0L08B6EwyJh9gWmf/JI4iwlG0KJ03HHMsWhH6wo104bq7+bS+qoW+uvkVRu9m3M6zIGH/ybQsT36yjC+NyJEtxUHlF+jvIcwVncnv/RFLEzUjCnPTAA1xjF4DYTg26+0V2YLFLFdUP5Te3DSzMxd1hVUZqr79ZWT+65/3hXvsPbm/g1DAFDR2qyhTQPsquCpDRJzeM8kthKFdACpUcF8fl4zkiAWj1WzilHIT04RiJLR2/7rIrnaF35clF6UKH3WdM0dBMpw8lOzaymglgFRyvjyoAJSM/Ge1F/28jMC7TT2YwP2FugQfpevgpVy2ZJtMoI1pWfPMxjCJyKxY+MXKPgT9CZBCTp4O1A2tu7/QkHLaniDLjp3PT4YkYBijEzIyJbJ8ReqAM3Uf1CwUWnFU0CIRH4FeO0SrPfWM5TzigPAEy8PnK8lRL98p7eua/9uEHI//wTu4LIF77+luVXLlqGH1gbz4/aW1w+3NGmLRzTA+oS0In6L/FVn2khXGfAhWz0ATXbAjh6nEELfBPOhpZY6eKj6yL2wOeG8al/fdbbehl3jV00cuvAfY43CxPypb6q7oWpet8qRPvWNaAopORvTwbZXBw6SmrSO0uhja2lhTJCS/na/iHHaJyYbgvT0IjLTw/L9jYuGyKbXX2y+gg6MdeFg5P1UG7Hvs7AD2Ij9MzmBOagfxTQKToQB4jpge8UCbtjO/HYgNTCNf1+6YAq77dNwlcB88cgPywWuXHKQtyqGCrp+Xl4w6pZsCN6zfv3X46Y vGVTz0nM umpVHsvbvRe1XYiBXm9xr4+SBOeBWOcR0+4dWeTTr2veTElzffcpN9fgDv2F+Kq1zeHAGCfb9K+MS6dBEsBsBRN5etYO8eWskqmppM/zBRMGiBTZdMtwJXUSowg26uhp+NK+OHGWNzvXiXxk1za0F9ktO7tTPRpjrP47dmpzU9ppL3/1XjG9pE1WrfDHruYDlx24VbpjbdbBsvY7+0wH91oMTe9ax+3LYOJf4TiIGADnqaQkNcE9QpPGbEQyXKY/pI6KPVwqgEUEEQU2BjcxgZw36CtYj3QZNiQErFxSnEVugTTs+s9Eqd+sBwbIKFAxDXGRcl39b5VjTGPmJC8QHVWJRaddbPt4GoEhE+R22U5LnuahLGwc3/gCsvg== 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 Sun, Jul 16, 2023 at 6:58=E2=80=AFPM Yin Fengwei = wrote: > > > > On 7/17/23 08:35, Yu Zhao wrote: > > On Sun, Jul 16, 2023 at 6:00=E2=80=AFPM Yin, Fengwei wrote: > >> > >> On 7/15/2023 2:06 PM, Yu Zhao wrote: > >>> There is a problem here that I didn't have the time to elaborate: we > >>> can't mlock() a folio that is within the range but not fully mapped > >>> because this folio can be on the deferred split queue. When the split > >>> happens, those unmapped folios (not mapped by this vma but are mapped > >>> into other vmas) will be stranded on the unevictable lru. > >> > >> This should be fine unless I missed something. During large folio spli= t, > >> the unmap_folio() will be migrate(anon)/unmap(file) folio. Folio will = be > >> munlocked in unmap_folio(). So the head/tail pages will be evictable a= lways. > > > > It's close but not entirely accurate: munlock can fail on isolated foli= os. > Yes. The munlock just clear PG_mlocked bit but with PG_unevictable left. > > Could this also happen against normal 4K page? I mean when user try to mu= nlock > a normal 4K page and this 4K page is isolated. So it become unevictable p= age? Looks like it can be possible. If cpu 1 is in __munlock_folio() and cpu 2 is isolating the folio for any purpose: cpu1 cpu2 isolate folio folio_test_clear_lru() // 0 putback folio // add to unevictable list folio_test_clear_mlocked() The page would be stranded on the unevictable list in this case, no? Maybe we should only try to isolate the page (clear PG_lru) after we possibly clear PG_mlocked? In this case if we fail to isolate we know for sure that whoever has the page isolated will observe that PG_mlocked is clear and correctly make the page evictable. This probably would be complicated with the current implementation, as we first need to decrement mlock_count to determine if we want to clear PG_mlocked, and to do so we need to isolate the page as mlock_count overlays page->lru. With the proposal in [1] to rework mlock_count, it might be much simpler as far as I can tell. I intend to refresh this proposal soon-ish. [1]https://lore.kernel.org/lkml/20230618065719.1363271-1-yosryahmed@google.= com/ > > > Regards > Yin, Fengwei >