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 E4271E94107 for ; Fri, 6 Oct 2023 19:53:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 498AA80015; Fri, 6 Oct 2023 15:53:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4499680008; Fri, 6 Oct 2023 15:53:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3384380015; Fri, 6 Oct 2023 15:53:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2594880008 for ; Fri, 6 Oct 2023 15:53:40 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id F0347160146 for ; Fri, 6 Oct 2023 19:53:39 +0000 (UTC) X-FDA: 81316086558.06.A357DE4 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 6D433140007 for ; Fri, 6 Oct 2023 19:53:38 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=JeZ59nx3; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696622018; 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:references:dkim-signature; bh=af76HINdXZQ8Y/mf5JDWE5ByRVzuBZqQgi0mKK7ATyA=; b=Pou9iicrsjoRgj6u5MgN5LtBDqLwA/IBJ80CyG2q3wyJlGKZenZObGVm9jsuUpv3BGJ1mb OpWmkWp/V2VduwS+QxuD3Ywjxysv8Xeg9mqKYn766z2JhWNHSZNLzs3vwf8lZy3L9UNMxh 0BiLTMfHHB6zhyXtJK0RMID/v1PSTGs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696622018; a=rsa-sha256; cv=none; b=lT5jszv8wrf26CLPCkinXd2iK7YaPyJIQH9TARiBi7ZiJlPlXDMi74Ugc+u/8q57eRYRbW Uj2kaY177flqm9WjtdP8Tw4s/y+Y0ySCLBqU5dGym2Xm1kFSROvMP24sV8d9mgPkpmalpX rkPcgtYy6ACgHAF6KglRkgRu/fD9gus= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=JeZ59nx3; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:MIME-Version: Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:In-Reply-To:References; bh=af76HINdXZQ8Y/mf5JDWE5ByRVzuBZqQgi0mKK7ATyA=; b=JeZ59nx3dB7PTSrUv6JozHyZwP S+M2F99fD5AWIcIwpYqDd4j6i/Kbpr121r4y4agO/kdt79NKYeIzREXVdDaFZlDwnyGpYi2EDXz48 SzamUOI5vSUfZdqkPG0a4NmYBHy6b/uryqlrUDtzxXNEP4Szo5Zm+t3EnoRvqfQvlpw1waX4kJGc2 1XK3fawErxCn4Nh8/uRO+iS/Wahya7fPcy8RG8rX/waphSVUTBEtz2rPmhIgW9WKdRDFedARGUsCM 9tReZze05D8omEC+FT0O0jk+veiiJp/mquWG3jkMmgAOc95svooby0jEYV6gHnypF1nePCnhcY2KH CWKkMgqA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qoqsy-00H9GQ-Dd; Fri, 06 Oct 2023 19:53:20 +0000 From: "Matthew Wilcox (Oracle)" To: Andrew Morton Cc: "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, Suren Baghdasaryan Subject: [PATCH v2 0/6] Handle more faults under the VMA lock Date: Fri, 6 Oct 2023 20:53:12 +0100 Message-Id: <20231006195318.4087158-1-willy@infradead.org> X-Mailer: git-send-email 2.37.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 6D433140007 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: rnhkddb8yupayr8m9h5fkum7uukwtedg X-HE-Tag: 1696622018-756449 X-HE-Meta: U2FsdGVkX18obNe5oYu7Av6oz6wkVCF8GEa54NiDOTUoQ7yiUfYQ0M7onDABfy4/e6CYGxjXFWaXGCwaUCDpMW+/IQmiVUfeeo7OwWR104v7bH+P8D3IUnBPDd9nbKSogYs3K+gmFVDfepkc6WrbEdx0m7c70MS2ZOxS0LtxNQEegNl7Esa4ZeNlgud3oaQGNgkuGqxbJWxTJNhwpI/FzBFxoLkJFgEdU7TQHK8ol90IWWYAj4HGheoubPT2X++uvP742fumx08u3mn+bSe3bk6VkxoS33XzUVHq5x2zoAAk4vwAJN2OznlRyfxAk88Uf8YGTmh7mGEIYd1RjKXSldmzHIdrainkCAK4nqzF6ooyJmFyKwaeE2owcfIigdtF+GCZ8l0Nn1C19Dhkan7U5OpRNvLaFZnOfvFaFLlzWF9MmBYVObgYVjoGkm6lRXtX25HOQocf9HG4GGE2rWndT6bzoVUMaxalRxZfbY8R5Budrsrn14/oLz6ftyH6gXCetEW9OA1ZBNz4lEEDr21DMUKntQp9BgdZZLJzaMP0ttqkQLqRiMmOzxc3iDp5uFgd29qzP03st+veyJOFx5rs8a1aZKgFTW2KyN4tZGY2uZ20Oc1UtHXRo2CCdlmX6vXIIEFfuNnzLrXu7DCXleojHS/ZNNO7iNIKablIS83i8N/5oTpNXFRUsl0N1dCbN9g69td4s+Zac1X0IMXY8p6qKhRDef/QHifROIlH/q0G99anoKH6ddh3cANbV+g/LBfhXHiYSHcPc9LCz5tbr1mDEQnf9VlKpIzOJPjMZixwf4jWvMxBiW5qaU+5U+ftEZXFEgLa8pxj+rzrjE3tzYPBq9QuVsry7oyPP6HOlaM74NPeVt71kPt7J7ex2FLlj7/w1cg2R1KBhdObNKDRD3RMA5H8HFdgmVQWYqlwdmeDm8n0EMIGWWH8Dq58q/qb+83uo2Id5CTVnXZVRTAdUMA eJK6zqC0 Xddk4AYuk5zpSatNorb0Tv/LPACTvh7qSEIw90mDED+cg1SDv/GGRyVudLs29hL1HVW3lWnweSdSTKGElBnLSaeL/vk00xi0Wt3wDmRR/jhnA5JEaABUA3ZduTg== 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: At this point, we're handling the majority of file-backed page faults under the VMA lock, using the ->map_pages entry point. This patch set attempts to expand that for the following siutations: - We have to do a read. This could be because we've hit the point in the readahead window where we need to kick off the next readahead, or because the page is simply not present in cache. - We're handling a write fault. Most applications don't do I/O by writes to shared mmaps for very good reasons, but some do, and it'd be nice to not make that slow unnecessarily. - We're doing a COW of a private mapping (both PTE already present and PTE not-present). These are two different codepaths and I handle both of them in this patch set. There is no support in this patch set for drivers to mark themselves as being VMA lock friendly; they could implement the ->map_pages vm_operation, but if they do, they would be the first. This is probably something we want to change at some point in the future, and I've marked where to make that change in the code. There is very little performance change in the benchmarks we've run; mostly because the vast majority of page faults are handled through the other paths. I still think this patch series is useful for workloads that may take these paths more often, and just for cleaning up the fault path in general (it's now clearer why we have to retry in these cases). v2; - Rename vmf_maybe_unlock_vma to vmf_can_call_fault Matthew Wilcox (Oracle) (6): mm: Make lock_folio_maybe_drop_mmap() VMA lock aware mm: Call wp_page_copy() under the VMA lock mm: Handle shared faults under the VMA lock mm: Handle COW faults under the VMA lock mm: Handle read faults under the VMA lock mm: Handle write faults to RO pages under the VMA lock mm/filemap.c | 13 ++++---- mm/memory.c | 93 ++++++++++++++++++++++++++++++++-------------------- 2 files changed, 65 insertions(+), 41 deletions(-) -- 2.40.1