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 7EDF8C001DE for ; Wed, 19 Jul 2023 14:26:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05381280067; Wed, 19 Jul 2023 10:26:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 003CB28004C; Wed, 19 Jul 2023 10:26:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0EB6280067; Wed, 19 Jul 2023 10:26:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CEA5128004C for ; Wed, 19 Jul 2023 10:26:22 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 999C01403AD for ; Wed, 19 Jul 2023 14:26:22 +0000 (UTC) X-FDA: 81028586604.22.C08559D Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf10.hostedemail.com (Postfix) with ESMTP id 93EE3C002F for ; Wed, 19 Jul 2023 14:26:20 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=7jfU311s; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of hughd@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689776780; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2VK55DG3Fs7PTghAKQd0jM8nvqZIPZ4glcR3HhFBT7c=; b=pGK6vTF36ZqvhO92WWHuDUOnS0gvh5c9R65RapWSWOhPb5OY6pV8CPzyiKgCFldjWyQzNi s5LIfYlVE2k16Aquy5vh+/IN6etKRll7qKLodnrzX+6oRpjfcMQSCHVpq4Zfm7peaS53/6 i+pbhmu1fqaiQ38aa2IuOIvTI5ktDVs= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=7jfU311s; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of hughd@google.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689776780; a=rsa-sha256; cv=none; b=49OM7XFWPTuCcv8Hq2+ZlB/IJmVb8qXMFYhU31r43eEPlbPKr0P+9zU9KKPZqlq6cly92f 58alKXAxpM1LHwE5BSL0Z8g8r960foykZAw4bZ4/Fz0Max1MMz67OrgCO3rxifFyY6adC4 xNR/zghANT6KxqjDs+SDBDPBPC45Lq4= Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-caf3a97aa3dso7249354276.1 for ; Wed, 19 Jul 2023 07:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689776779; x=1692368779; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=2VK55DG3Fs7PTghAKQd0jM8nvqZIPZ4glcR3HhFBT7c=; b=7jfU311slUUW0UFqd1xP+4htLveZmM27w7SWA5P0Ofot830W2PGNGcLy4HrhdEoxQm az+ILN50Jzlo4maRmOZlUhdjCrGtxh073DOAMOQlyZCSdcDvxCsrVoHtWECGQCV6CMYP dtkRMmL1WsTSmqNv2tW3j4A1S23poCaDbO2S1YBY1oW1aMQtTEPf6UsRY+WbA+OtKrIC Ua7LPGLJzdckrb/5yRJ7bC/gRfLRRWFwi+VUOyu29ro5uT5rEQHlXpAaCoqRhr+mHIqE pK8dmPZI3dsvbXSSHF64DsP7G2TTHotWz5S+oM6rCmanQUB6ET0h94ELWpdpUDirIPGy yX7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689776779; x=1692368779; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2VK55DG3Fs7PTghAKQd0jM8nvqZIPZ4glcR3HhFBT7c=; b=SiclX4c67k4VyNeqJJdonqHq1Ama2trkG8GyjnvX6eKJ0jHgPluj1TjeB3QrCJLmPT KXD4YB3zmxhO9rdJdCa46pbNFxXDNUvhjJhOGiBA50t3wJX+3DmTkSF33zZb6q+qlBBB 5nShUCUKbk/VlrBKkd4a3favagRZ4XjmbfRwbMv6kHjzZLaFtsuq8YwsG9+9eMwGkd+8 MlkV0cN4jCMfVB4rAGInolcUb7310gcTK5Q2cDs/DxlpEL7aqYkVb9MJ/RAPN+3haEXH UVHwvI5dcDzKfMPcfY4x/2hrgzX0+YAt9apG5uSvSHZ8fbQzpkNHQ8ax6mLbPwF0ozYm ysqA== X-Gm-Message-State: ABy/qLZ3r9z2o/7l3Ya/PsfnVrsfhLGL4Px4Nl0BbQp47OPiMJ8jnCgq AhpxlBmprYlJSMUPyDS32IAolQ== X-Google-Smtp-Source: APBJJlFkic+Ri/Zc9kWO4O0LpFmkfS6fsW6kTdiRwmfAxsS9VkTkZur4wtoBXB7B9HvqhJ1+BGi7/g== X-Received: by 2002:a25:5342:0:b0:c85:d8b7:1b96 with SMTP id h63-20020a255342000000b00c85d8b71b96mr2356398ybb.52.1689776778840; Wed, 19 Jul 2023 07:26:18 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 133-20020a250b8b000000b00cecd504e708sm651446ybl.35.2023.07.19.07.26.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jul 2023 07:26:18 -0700 (PDT) Date: Wed, 19 Jul 2023 07:26:08 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Yin Fengwei cc: Yosry Ahmed , 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, Hugh Dickins Subject: Re: [RFC PATCH v2 3/3] mm: mlock: update mlock_pte_range to handle large folio In-Reply-To: Message-ID: <79f6822-f2f8-aba4-b517-b661d07e2d@google.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 93EE3C002F X-Stat-Signature: 45fp3wkc3tnfdrgwf5id4he5tp66xd8r X-Rspam-User: X-HE-Tag: 1689776780-637805 X-HE-Meta: U2FsdGVkX19KnMutJmr4XatPgARHnelAyJzr39nz+U21qH6FiZCTGX5bf/xft7yVe5zsahh2ULx9BznCfXSzcSZzrSaBppzlmND1OoaB1lRJ2jqr/24mpEFQtSqgiVged0OCVHauz+c41fqm6HbmuzSBbGO82womd8OGjtb55ktGRIucZsEwV8dA5Lv6f9HT+xedaoYIz7oZaPzxKBogRXAphkuQJLakh1GfKodADXd8y9bVwvpR5vyU6LXui++sacXa0rgSqz27GNwKbMTNJ2ZWIp3ThS9uqyffo5a3JHl8DdlYpQ6yIalPrOyJ9zRkTkW/uuJZCv1xU3jvkL1OpHjT5a84dALTZRzzofH/d0rfszOmPiawol1hwQqY5xSXtEemSLr/VZvib6K2cy4EI8TZpB9/F0qxC/6E4STE168o7zZgrNdBYHeEihzMaQHu8q1exz5ZVh/qZ5IDNr0zAT6iUhC0G0JhX6GgdfLSL9INWvb+v/XueUhnO05F9n9c0mzQ18wF/D1EHubdDcGE2Qfpe1VTNFgEBj5NcfIRjCmOF+7TLMhr/V8f5RKWMnmuiQpYhrMmwHlnwGm/rM99wwqVe+3KnHYG9hVNzfWJcT4FKs8/WFisgyZ4eqlE9qrVNT/dwh9wgiUNkSX1Xf1JWUalJOf8gdupDArE2Y9IlUYwx8RUi3rAtHq3MhKWifqZfivbXV2ZewFlp6xcKatEvaSIpY/m92JeijqqmiJCHVgNigmG0Cn0DIYVJ3M1ZR+9yNgQQkTIBFNTzT/SSrwDcLbkYeVOE3i05i8Y1xhd5olbY6aZHeHMNQUN/7YQwFrr7PKUJY2lYbEhXO4XhHniORgIDZ6e2GVtdBv2GBJ7+zxByjdj7/epQl9NWL/KXgdd8oejIle5bLX/55sfXeJeIDB6gklIG7q0lexHV/tAp7HykzyqmVIsLGcLFrj5YnX72r9d1eYFb8jmOLxsZol fOvTwsoi V8waP53ngjDRewR6nIWlv46DdZqLOtc2QCmGEPck2/FbF5REEQWitipBWwRjCL3IaAdkLFoJMrNpCg2zdfWYBEZGEKqx6+R2B+ZFKpvKg89cNGpKvUPwV3cJKTbU1WrCa8X0mZVsIoUsNwhtQoP0PCLoG2FJbcF5EMTq7IZnSQH8o2zZVxaICnFjukbkeWyUgNGnx2XFZvDp5KF861wk+3XJeXhqRaJQKs3y6A8tmNllpODvfYO9xLRA+Ds464dUGPiOmUP6FdjjMFGSLjh4xnw2khRd0t2Zt99uTqb//lls30Jhj5God31K3YbipvQdH9qzoml4f9i6HBSLOPpDpzFgwMa5e3z7dOVuP/cEV3G/n7qZdCb9ldJL9lMo5NT6kvzHsIpM9xkitDGpQpvVzH1vBmmohpQQPjtms 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, 19 Jul 2023, Yin Fengwei wrote: > >>>>>>>>> Could this also happen against normal 4K page? I mean when user try to munlock > >>>>>>>>> a normal 4K page and this 4K page is isolated. So it become unevictable 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 unevictable 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 right: 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 because 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). 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 whatever spin waiting for PG_lru here? Hugh