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 D6A18EB64DA for ; Wed, 19 Jul 2023 15:44:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43033280071; Wed, 19 Jul 2023 11:44:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BA1328004C; Wed, 19 Jul 2023 11:44:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 232E9280071; Wed, 19 Jul 2023 11:44:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0DD7B28004C for ; Wed, 19 Jul 2023 11:44:58 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A52FC402F5 for ; Wed, 19 Jul 2023 15:44:57 +0000 (UTC) X-FDA: 81028784634.24.C77FF1D Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf15.hostedemail.com (Postfix) with ESMTP id AC82EA0003 for ; Wed, 19 Jul 2023 15:44:55 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=updgacmJ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.42 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=1689781495; 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=kvTRswu0hNwAHamKZsbNQPwa1H7EMVRdLQIS+OpsXqk=; b=RSS1BKJ+bXQCwNLmyyzzu3SqjVixx29VR0JqgiyK24+KgCc0SBhsIFU/085+QjvheTBVTW +gM6yY4XLYasZHKFLzRX3o4LvHYrh4MVfQMPqRBRapF5r5zpaldmstaAGMmCthtKSqlE/X 8LLS8wusD+v8iOniAUCtm8bjBHS7TGU= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=updgacmJ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689781495; a=rsa-sha256; cv=none; b=uqgySRD0xTXjLTOxdYoPBTUNIjkTG4ul9tV67kT+iFjsIpur+caaFlzF90NbRGLKqYmNjW JkVwXTUB3hMlWJtD4eC4xNX/uivqN2FoQFlzZAF9vZjgF4UL1WWKZgXm8m0wujm/ajnJvC jn32XjdB8ZLuLHAFYVJqsPNRs7Z7JDM= Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-9891c73e0fbso205804666b.1 for ; Wed, 19 Jul 2023 08:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689781494; x=1692373494; 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=kvTRswu0hNwAHamKZsbNQPwa1H7EMVRdLQIS+OpsXqk=; b=updgacmJGqD0Vkf6dmMGGr1c5ss1RfXYXFZCF6aa0VJ7tK5drD69T9VXxxfY0K+5Jp tSBG+avaOK2SafoVJrna/vznv87ChWqBUh1qjM4ejfTplwI/xgVEPchs++rUHuBu27gk bWGuZgIcSojwjVHBJqAUPM+Yern8N5QPScE27VaEeFeXwjiQ/ca0J7CXOoUatMfy+0Hf /CkpTffwOaOZL+rKZGD1TrXrDxp2yrlxCOKWYjiQp6W13CwBsxDPIJw2XFDCbDJDZsBQ bLKGwk29sK+D8foW7xTv/uHvtDgVts073TdTJU/N9a4jjlf3Eu6e2Vin1P5zbXmBDQZw pQ+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689781494; x=1692373494; 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=kvTRswu0hNwAHamKZsbNQPwa1H7EMVRdLQIS+OpsXqk=; b=QzBDu7g8V/VXRkf4LEfh1N3ie1l3Rm190out1fJkbs4CZY93vGy42sK9EYgH8mQldm 3x+Z5C8Ctzn/N4Rcjbj/SkmC2RHLsH/94pJ7aSPiWIh2prGYnMds0yzrK/IsWSZOVFNd 18mf2QezE6VT0Xb2JtlIbs05z0Wowgr5nhZV9vC5IDAzUfre/IoQkzIwf+onc+elNzRZ 1Nd5YycU8M3+cbzkeQ+kDNt5TTShyrICOnAMGp4br9y3aVxFhKQINF+L+fk/STf2XxTZ d/qm5b35ZWbmKcK+/T68x/rT2+9pKyrRKvLy7SzjLoJcDYyXab2mllckOSE8AjZ79Avv wENA== X-Gm-Message-State: ABy/qLa/Xmp/H4Nt2E51lNkJh0auVfhWJuDozrrPn88RGO9gd8BWwoOr CX/GADo5Ox9dq4NyjZ2Aj9GM0LrZyGPKTTxmjbwNPg== X-Google-Smtp-Source: APBJJlHf+g/spbm8AIPdeL6lOUB/vFhqyar65psraZkp9NEeHY9jCu+ydUPJeNcJqtCQKdugl2YoGqCKx0hEwzS8DIg= X-Received: by 2002:a17:907:a42c:b0:978:8979:c66c with SMTP id sg44-20020a170907a42c00b009788979c66cmr2880098ejc.18.1689781493979; Wed, 19 Jul 2023 08:44:53 -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> <208aff10-8a32-6ab8-f03a-7f3c9d3ca0f7@intel.com> <438d6f6d-2571-69d9-844e-9af9e6b4f820@intel.com> <79f6822-f2f8-aba4-b517-b661d07e2d@google.com> In-Reply-To: <79f6822-f2f8-aba4-b517-b661d07e2d@google.com> From: Yosry Ahmed Date: Wed, 19 Jul 2023 08:44:17 -0700 Message-ID: Subject: Re: [RFC PATCH v2 3/3] mm: mlock: update mlock_pte_range to handle large folio To: Hugh Dickins Cc: Yin Fengwei , 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: AC82EA0003 X-Stat-Signature: 148rpedqb3n8p6co71zryu4h495jfj4f X-Rspam-User: X-HE-Tag: 1689781495-132146 X-HE-Meta: U2FsdGVkX19L5Vom9WWswKlQe82o/+B7Wp0txt8f9Wv1JGWb5Ff/UAO2LiESjcBCzF3VYIqoBdoupMYjppnx8mYCwMxbuK0yvpO4BaTa+LH8UF0WOIRvhCjOip30UJbteWzDtM3Dcdt3WZU/jlTIrL2kRKYN4QjbrfeZF3L/PAGCk3IWn2iES/E8PchHzXdR45TRzbazoLTVHXusyvWOs5SLPpFZstTgPYgz/9MOgUt4Ih9cXwPKOSndCzNBhiM+QijRvm+e+BLhpfZ9ZKS6aHzYIYSDYyz0J/vhNEks9t26RKjvc/S80Wz3LFZwgs0JoXGQYytqVDgeTXwBuBxa63YZwlAFeFWPUm4GSYXW1PTJWndemEHtJwprUKQw7a706TTPM8Gq3jpXAqmlD/63+EndZqm+2H+Acb/I1qSeGYPDkJ0LR6mOabsbEspaNLvPUQ+VDpR9NfVvZp6ntIflpN4FNmMNebBalXX7wQzPXQqVfYOdb+xFve80JAxMX2GtpZ88tJYW5ttqX1YDsda+M2k+BoxOwg7ZPOTW6R2CDSqgwLFPT4c+L35kYWFZT+D5jF31TReIrsnCHWlHVt1lN0eTj6m98hKUfSJRxHo6/kyjwiwCo4is41lJ5XH6u4z6FzbItXth0Ha4YfCqCsYUENqEwOJ/kuOYAAaTyLzIgEabaNJqcnbdSnkY/FjuvZzW1HzOovRO8E8y9ZJL5At1HeL4KkTTwuQ7oXaztAvMqI8Pc5T7qMEfEo0ni2ySF9+Afta+MH268sVBYi6yxQ04WDbPycMyArU0GWnirYX5nN7eE35nGsRA6DHcLLWRmYOp8tG6GWHRT5FJO6WbdwuMCm0X2PcOpj5s44Mrp4WSsIEqXMf42pwzBvDCD+nihhqguToTEJEztUN7OvlLY2AYyR7DIvjvs8CRGkKA3VmKnaCgElOCezco5+VMDiSIuUCcSS+iQ+InbiJbhAnLyRW DBwT1Rv0 98MMiKGowDWY/stxWk5jwi63WwN9f5a5bdymIF7FRzOqLgLN0RDralcFEFCypVtxNFJLwq6njQxvGUw29KxroHh4se2EIu9RYUmBHOpJ8NXv21pO4Ufnt43zyDqkdyA3fji4g+Wmq4R4yl+E4OsTKCNvJLkKIbO3QuZwlLZ9a8HVh+GpOlSlGSg710W9k7hfYlZ7TTSUT5qnJfa1P8cq5cZQ21Tj9dBhb55T0INwMuLf5nS/wP7aE4V/4chmKFoZPig1CFCK/9+67aqxPg5bYkCVgT4Gosu0d4feyQ7KtSJIzRLGXdhzj4sZeOj2g9mBuXK+Zdiok5mfXWFvhDS69eEYqJjsqGku24znHxFPR6yy18WA= 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 Wed, Jul 19, 2023 at 7:26=E2=80=AFAM Hugh Dickins wro= te: > > On Wed, 19 Jul 2023, Yin Fengwei wrote: > > >>>>>>>>> Could this also happen against normal 4K page? I mean when us= er try to munlock > > >>>>>>>>> a normal 4K page and this 4K page is isolated. So it become u= nevictable page? > > >>>>>>>> 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 unevictabl= e list > > >>>>>>>> folio_test_clear_mlocked() > > >>>>> folio_set_lru() > > Let's wait the response from Huge and Yu. :). > > I haven't been able to give it enough thought, but I suspect you are righ= t: > that the current __munlock_folio() is deficient when folio_test_clear_lru= () > fails. > > (Though it has not been reported as a problem in practice: perhaps becaus= e > so few places try to isolate from the unevictable "list".) > > I forget what my order of development was, but it's likely that I first > wrote the version for our own internal kernel - which used our original > lruvec locking, which did not depend on getting PG_lru first (having got > lru_lock, it checked memcg, then tried again if that had changed). Right. Just holding the lruvec lock without clearing PG_lru would not protect against memcg movement in this case. > > I was uneasy with the PG_lru aspect of upstream lru_lock implementation, > but it turned out to work okay - elsewhere; but it looks as if I missed > its implication when adapting __munlock_page() for upstream. > > If I were trying to fix this __munlock_folio() race myself (sorry, I'm > not), I would first look at that aspect: instead of folio_test_clear_lru(= ) > behaving always like a trylock, could "folio_wait_clear_lru()" or whateve= r > spin waiting for PG_lru here? +Matthew Wilcox It seems to me that before 70dea5346ea3 ("mm/swap: convert lru_add to a folio_batch"), __pagevec_lru_add_fn() (aka lru_add_fn()) used to do folio_set_lru() before checking folio_evictable(). While this is probably extraneous since folio_batch_move_lru() will set it again afterwards, it's probably harmless given that the lruvec lock is held throughout (so no one can complete the folio isolation anyway), and given that there were no problems introduced by this extra folio_set_lru() as far as I can tell. If we restore folio_set_lru() to lru_add_fn(), and revert 2262ace60713 ("mm/munlock: delete smp_mb() from __pagevec_lru_add_fn()") to restore the strict ordering between manipulating PG_lru and PG_mlocked, I suppose we can get away without having to spin. Again, that would only be possible if reworking mlock_count [1] is acceptable. Otherwise, we can't clear PG_mlocked before PG_lru in __munlock_folio(). I am not saying this is necessarily better than spinning, just a note (and perhaps selfishly making [1] more appealing ;)). [1]https://lore.kernel.org/lkml/20230618065719.1363271-1-yosryahmed@google.= com/ > > Hugh