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 639A9EB64DD for ; Sun, 2 Jul 2023 17:50:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42D298E007A; Sun, 2 Jul 2023 13:50:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DD448E0059; Sun, 2 Jul 2023 13:50:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A4F88E007A; Sun, 2 Jul 2023 13:50:45 -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 1C1928E0059 for ; Sun, 2 Jul 2023 13:50:45 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DE457120123 for ; Sun, 2 Jul 2023 17:50:44 +0000 (UTC) X-FDA: 80967412008.06.10B0359 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 1CB8E140011 for ; Sun, 2 Jul 2023 17:50:41 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=gsSTkqum; dmarc=none; spf=pass (imf26.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688320242; 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=qtq4xZmGJHF0roAxc5vd3g28SRKktcLfa1D78W6Jf6I=; b=1fteVpZtJQ1KF+4kvfg7xvD2kLR7vGUC2uAd3Wh/h3hAXekuoVUw722HZGUF55A48vDqY0 qZAVPKLhqcp883kv3rujIl/hBq2izMmjo1C/WtCwsg2w9B4vswZTcyEg+ObfGrH9kyeMH9 ZTlWKOeFjcMmtvYlRuR7s2Xcfvh0bT8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=gsSTkqum; dmarc=none; spf=pass (imf26.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688320242; a=rsa-sha256; cv=none; b=KsIo8LUOe8VuTRiPT1/prmn0X1iovB9qJ+ep9pSoN+9EJwk8YbSB3K9CXflEL7xoN3JHks nglP2TfZ1XtsBeAk7RNeo+TwonDZ5iHkw+lXlMVlt95r2n+VXr8MoARN1YB+gGzSGPNqRN C5Ec5sMmj5sw9OCKaMxE8mL5NUtYtpo= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 021DF60C52; Sun, 2 Jul 2023 17:50:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29493C433C7; Sun, 2 Jul 2023 17:50:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1688320240; bh=qtq4xZmGJHF0roAxc5vd3g28SRKktcLfa1D78W6Jf6I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=gsSTkqumocKHhTHBiF5BxV7PJywcvJ65EU/wzK3pcqggkdIOjqXoJGHeJkLnV2SOQ LprCWHTOTZJdHrnbySXPI88NtO2xcDPjaYotcqNyoRNn9hmYU6KvmFF5qn+GV+AvxI qA+UvqgVsfUu3tbRA/XulHtN3BUIUKwRUrxqv4PU= Date: Sun, 2 Jul 2023 10:50:38 -0700 From: Andrew Morton To: Suren Baghdasaryan Cc: willy@infradead.org, hannes@cmpxchg.org, mhocko@suse.com, josef@toxicpanda.com, jack@suse.cz, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, michel@lespinasse.org, liam.howlett@oracle.com, jglisse@google.com, vbabka@suse.cz, minchan@google.com, dave@stgolabs.net, punit.agrawal@bytedance.com, lstoakes@gmail.com, hdanton@sina.com, apopple@nvidia.com, peterx@redhat.com, ying.huang@intel.com, david@redhat.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v7 0/6] Per-VMA lock support for swap and userfaults Message-Id: <20230702105038.5d0f729109d329013af4caa3@linux-foundation.org> In-Reply-To: <20230630211957.1341547-1-surenb@google.com> References: <20230630211957.1341547-1-surenb@google.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1CB8E140011 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: qgfgiwbzzs9fggmz7h1uy93mfj55gxoe X-HE-Tag: 1688320241-302468 X-HE-Meta: U2FsdGVkX184BSRzP142vE9spTYpELYDOz84gh2QzUR0WlwMw3MDoubEabEBGLqirjX555di1OcU9tcdRuiuM7BmsGn8h0Z95gPnqif9M41msuzKrpE+tWep0cgZ6+Hw3ql8MCnOoH4TOobyaKeRLOiv4dnVss6+xyy7oY5u68gN02uSXkLrnPSp2jdtdBLgPA5Oqp51CXwcRufey/D5MA1Z3xbdPfNwEnvrz0LAryHQr+6QGG2LtPN9/L6kElt/Fx6cUCXfdj+/V3u9uZQ4etQntu49zi4CRcHhVLijqFBXa+T9a5hw8BI5dW8dWkI7HHs69C5coZB4iYBc04KID+sSivNDtL0zVoT/VQ3SsGFUNPphuk+0CQXzgKiqA2LSQAF51Dmd2ZoylH2KEdb0GtYkIpv7dDlX7fiu/BnqBzQ+nJvvo/1Lyu1Jlylru5gOjsOzJaw0SMhXQorq1/lUZRSAPdeBEDu1Uo014BrxRJ2asaGk9BDSPV9B/aPaNB0dTtMc91kimAUnuU9C9t8B6uZf14G/divZZFOI0tgxJMex3GYl0tBZFjnA9wsVpFE0s9XerpT00Nq2NbH/uTNqRdJ8zclRlFI92wBZdGqzk3W1jMcBN/xR2AErDWkYFjlHsbe7WJKZvfqsyijwrGrg2DGhjLeehlp5zYO+ZKRBWG3mAjKGjl0tMsGjMkBp99O3MQ5webZyh97gIuOhbS686QLAfzhjLpUuQFyRAUBv9dRIDe+ozFKv2NJsVenhbZ5QIBwborEpSaC/89g+pjRsiDA5gL1Ph1d9Yr4GFfjT8REPU5GW4TvAo0QiuIPgWWUO7tIFykPAjaqO8GC2KhzGPbNz6iM5Flc6jZqXHVQ5z7d43AdDdddH3hXF9veaph/QZVII3dQs+1JzUlaFSL/CYeJoSjHBdzPQjhAS97iUZQ18KdUniQDa5FaN3Bn4X996Fslcgc8A+/NiqBhVwbJ RsowyrwS MnsnR62sHxGqbPpcZYb669uVuJwD9zPXknmsUXR9lxRHHbXfLMx/5WRIOTkinmUO1+Z4OBlgj8fn9CbxmoCxR4xNShCu/q26/6i3J/Ryv/jJrcI6y8ybvjn/wpE3B8gJUzzIYBFzkLoXl+BxaAV6x/uzkBL2XqvBOvWP7CeCb64yyASdqrsmn/x7D+5Sf8A1N5uPGwA8FZl8ELvc2Z9bxJjR/jXFpiZhERbvprccrTz6YA4Tss2svBIwwiEicSiNOBVhJcDoYA2muxExV1gw0TQcLP6oRVPn0vf+ietummyv78SbJ3U58WtIXKDAT+NAZOMc0wrR6ld5mZfrT1tOnckTgDQrZw+uvGICl 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 Fri, 30 Jun 2023 14:19:51 -0700 Suren Baghdasaryan wrote: > When per-VMA locks were introduced in [1] several types of page faults > would still fall back to mmap_lock to keep the patchset simple. Among them > are swap and userfault pages. The main reason for skipping those cases was > the fact that mmap_lock could be dropped while handling these faults and > that required additional logic to be implemented. > Implement the mechanism to allow per-VMA locks to be dropped for these > cases. > First, change handle_mm_fault to drop per-VMA locks when returning > VM_FAULT_RETRY or VM_FAULT_COMPLETED to be consistent with the way > mmap_lock is handled. Then change folio_lock_or_retry to accept vm_fault > and return vm_fault_t which simplifies later patches. Finally allow swap > and uffd page faults to be handled under per-VMA locks by dropping per-VMA > and retrying, the same way it's done under mmap_lock. > Naturally, once VMA lock is dropped that VMA should be assumed unstable > and can't be used. Is there any measurable performance benefit from this?