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 AC146C77B71 for ; Sat, 15 Apr 2023 00:34:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0AFD7900009; Fri, 14 Apr 2023 20:34:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05FEA900002; Fri, 14 Apr 2023 20:34:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E90BA900009; Fri, 14 Apr 2023 20:34:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id DA164900002 for ; Fri, 14 Apr 2023 20:34:47 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9DC03802C1 for ; Sat, 15 Apr 2023 00:34:47 +0000 (UTC) X-FDA: 80681755014.25.26DF058 Received: from mail3-165.sinamail.sina.com.cn (mail3-165.sinamail.sina.com.cn [202.108.3.165]) by imf23.hostedemail.com (Postfix) with ESMTP id 3A1C1140002 for ; Sat, 15 Apr 2023 00:34:43 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.165 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681518886; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NRj6TORupyA9972+HDjetowLaxqXHZjUO1Wcr4/ofTc=; b=pSSKdQLEK2bq5LnmW/iba6oVRKruvVvb/2U1krI7K/92jWdETjJ2WMVKP8gwGtUuqsJ4MS svpeDlRpggwXo2TkkY+ofgJlkW3+B053rq4VWVrLv/DPqqOXOR2ZuPgMiz1ls0RFFgfJuZ gm2GQ5FUJnTCy5e/wjsyQJM0iS4BTUo= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf23.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.165 as permitted sender) smtp.mailfrom=hdanton@sina.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681518886; a=rsa-sha256; cv=none; b=yoor75KtY+v6iVov/GXblN912puLHkLVhT+rFd2WoqwwLq1vBLuv3HYA/4EC64H4P2jq/D f8BDrCcow4AML548Zf93r4a6EGsIsr2gy4yzNIpZz7UKB80CpVwQOOBshS1KvkZ0o5ZQQt pR5algNiiyJDZaA8L02okXnskAuF4Gs= X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([114.249.59.75]) by sina.com (172.16.97.32) with ESMTP id 6439F0DA000013B6; Sat, 15 Apr 2023 08:33:31 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 846142628875 From: Hillf Danton To: Suren Baghdasaryan Cc: Matthew Wilcox , Johannes Weiner , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] mm: handle swap page faults if the faulting page can be locked Date: Sat, 15 Apr 2023 08:34:28 +0800 Message-Id: <20230415003428.997-1-hdanton@sina.com> In-Reply-To: References: <20230414180043.1839745-1-surenb@google.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 3A1C1140002 X-Stat-Signature: a7r8s44z3iad9zko4gcdxjq9ht3qwefa X-HE-Tag: 1681518883-97285 X-HE-Meta: U2FsdGVkX1+by8Z5cUaSbrzFuSpsN9wuxJLeRhgoKcuoLwzJ9hwfwMMeFz8mmuZ+lIoyAhqsho+GjFMDcj8EiL2WxYf7tGFygGy1vIhfmU882EBcmLI0oal4cGYuGu82YQeedWV2PmEjItJrQbGz/17ZjZ58EHN/5EfdPjpV++X2w96t9ntxq62cQ83jFG6lsBSUcctJlJnPJpU0e0ZH9qqAelhQ45Yv6IGrvO6BJqPimRsr/yTZrZs7EnRwmIaLNIo43zaTNIDOIfAgPxz2JqAmt+Sbb7c+HFsXqeDm40Ri4XRUkTmWOsYR86XaA2hyhYX5yppOZEe14gOOXW9apcDAiTgSiKgvF+oFeGdhSUAR6RZEFWm7FJMVj6/p47QrVu3hfCkqFZon+aYiTuBwt84IOaiWLgsRungL3VPcOHt9c6U/Gc/pVu+miFJ74ZEY2EvL6l9pLJHjpKh1mGlFxXkvO3hC0d6tV2GH/Qbgpc9u/2Yvo0o3w3eVfe1xviRT0I7Dz3a9PgpqDsR38Rl6PigBbT5l6+BE5BgNtveOk8L/Zsi/LKEKQDVpyhD5E46EvjQNMrYhjTWtYHgWdtsXmbpdKfoDwLQc+sqHDL+IJL8CZBpo+lxrUXXdE1ETC/QMcrpVXlLTPbsMwhQo/0Siyoe1w5IXUtREf4OK3ZnM5pSejISQ4344hVNpTIB6yky+7g7E3yGsBnQ9QYkS+xhnHowpzD1iNCfW21n2iT+IXTQsa64C5UXrcY2ir83YPGQX7YEUepmyFJ/c7/0opVoZhNT7gy9LnZUsfOaapmcnggFhkZG63n8gMgFu5ZpRWyGJ9IuBjhnBqU6Umvy8kNoGUGr5WkmhipQyY/ed8n1Lfg23FqUyoO+PUNv6hpa3tdyEyIdj/fvIdJr/Yc2wP8Tp3s7a+lM5XhMeQrUGq5A184gxfcJdTZpAzTI3x84oEl8Z84zi8xhPS4mVsmvS2Lm bg3y0wfs p3gqVhVyOJi8SSNqHg14uI4faBNPGnSmzkC9M3w2Wsh6BblnKp3epSnHfpcX/lHemcoSjymu73njqX8DWL5Qo/q91keipiW88669HVrSbN0X1157qepTPnLQgVI3DZZlltJs4ctubDnAFSvac7IgtL1w13V/qR6zlSqgk5g//kuZV2Kk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000022, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 14 Apr 2023 14:51:59 -0700 Suren Baghdasaryan > On Fri, Apr 14, 2023 at 1:32=E2=80=AFPM Matthew Wilcox > > > If we simply sleep waiting for the > > I/O, we make any mmap() operation _which touches this VMA_ wait for > > the I/O to complete. But I think that's OK, because new page faults > > can continue to be serviced ... as long as they don't need to take > > the mmap_lock. > > Ok, so we will potentially block VMA writers for the duration of the I/O... > Stupid question: why was this a bigger problem for mmap_lock? > Potentially our address space can consist of only one anon VMA, so > locking that VMA vs mmap_lock should be the same from swap pagefault > POV. Maybe mmap_lock is taken for write in some other important cases > when VMA lock is not needed? This question adds a churn to my mind then after searching the git more than 30 minutes commit 89b15332af7c ("mm: drop mmap_sem before calling balance_dirty_pages() in write fault") rises. And John can tell you more about it.