From patchwork Wed Sep 27 05:24:58 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Wilcox X-Patchwork-Id: 13399934 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 CC115E80A8A for ; Wed, 27 Sep 2023 05:25:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D55B8D007B; Wed, 27 Sep 2023 01:25:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 55DFF8D0002; Wed, 27 Sep 2023 01:25:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FDA68D007B; Wed, 27 Sep 2023 01:25:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2B4FE8D0002 for ; Wed, 27 Sep 2023 01:25:16 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 06F8C140694 for ; Wed, 27 Sep 2023 05:25:16 +0000 (UTC) X-FDA: 81281239032.14.6861E31 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id 7D15F10000C for ; Wed, 27 Sep 2023 05:25:14 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=RLrXm5YJ; spf=none (imf05.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695792314; a=rsa-sha256; cv=none; b=GJ6OOqEigmA8xLSPrUIbTQz+CzRuDLZ9Wgx02/uHrVL0jZkt4wQ4iP65+Mr8G8J8ipxm8r kfIs/BqqIhNXL7ENneuwVx9EadhSLG5FPPCGhSQAwRq/cb2Wjno191W9SQ5SdEuPikqXA7 EycYzELUdns+4/L7LGx4mJfPAcz/tLY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=RLrXm5YJ; spf=none (imf05.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=1695792314; 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=PWn4w38bjPrg/GX4A62gAcI2Sp0Yao8I5LFO/vgxf9c=; b=jISl+yzrV+VcdPbVb+ixROPzmFYBhaJfPK9XC+E8RZnB98S8QHZLE4TO8W0JwrVuOcs0Lv tQriAmX28fiWfNCorAVwtUEd1VPeBAQkNXo2hrJxIn6ne7cuuz9YEAq6v6qvOFohQrwVzl Zr16d9kx5FsJQhfn1rJrBJCmU6PmMhI= 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=PWn4w38bjPrg/GX4A62gAcI2Sp0Yao8I5LFO/vgxf9c=; b=RLrXm5YJDxYxMjb2nd8UuqXa9S Bb3sL0Ar/i/FVS751031aBmlzFHF0NDDo6dmizK6YaETHxfJ/pkTWo2oasmvO83ygTBiOZqK5jQwy QQuiULXyR+8xGMooXVSx+ahpOmxzuAbAFhK6PHyeZNgfLufJfaoXYubLL2bQJAPkrlZYiMam5w9E7 4TBdhXXnFdNazU8TG8B5DtHQMLB6nP11nLZ4SjrxmWAGYVGwuYrW0/NnzsQrxBnJg6G9aMnmCp9lk Krb5OSXNUHLV/BWkPQwzQoCmrBZETNCT0q9jeFo+/dxEfdskn7A5TugtxGZA3ScluHYoMeCTDBJK+ hUWZMWdw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qlN2o-00Bywm-DJ; Wed, 27 Sep 2023 05:25:06 +0000 From: "Matthew Wilcox (Oracle)" To: Andrew Morton Cc: "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, Suren Baghdasaryan Subject: [PATCH 0/6] Handle more faults under the VMA lock Date: Wed, 27 Sep 2023 06:24:58 +0100 Message-Id: <20230927052505.2855872-1-willy@infradead.org> X-Mailer: git-send-email 2.37.1 MIME-Version: 1.0 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7D15F10000C X-Stat-Signature: m61kwutyngy4zeuenciussmtr1yyhnsx X-Rspam-User: X-HE-Tag: 1695792314-174458 X-HE-Meta: U2FsdGVkX1+kaZti/CA1AzbMhXXqCt7KgNZS9YFfl8Hd6Mv8v4s72Pn8V2zoK/XN3Ni+bOpG42W/V72PeoJ2U/rgL1YNN4g51+ACfZi/7ByaIAcBi+g+m/BsLIAiizbuIIXmDvUw/zzDyJEjbvleG5eqeYWNxZLlPFck34r9VQci8MAz3VHV9mjS3OBBd26T4IduxWQ/O9UYtOjScl3Pna/qFLclZP5LUUa1a5RNy3+FWbUWOM7cKABnyLM7S0cPZNJVaTqk63hK7kDArhUPBkCeC5Qsel0IVRoFUnhplIHbyMrEpe8EN2LFLUVdWMMkGfU05EimJ+OcnwU6SDQk71oR8SV5+1zX3yy8MAULqpvkNs4vC3H0lLUZ7E5vXXQ+2N4nD4/CZ7c8gAPWBMy6f+RyrDeWMrYh4K7ny5zi08pBnkHno+gcO+jikftR155bGlapCIQubnD4q9CaJ4hRtf4OZUbvX2rnxdEv60E7Q+W7wT7JtQ4/gpudTR4vAMoIvQC/Rzn3Sw9NxM+lq4RiBZZKNRmVmpesP+4RdzPDlq/2BJn3urqU4mKe9o+6+oymluWXm8AzPv5qdHWxT6NLPpwcNu31yYWBbWcdKeaPhU+Pgag/LBVTlbgUNVdEQkF/qB01vmreTOPGpbEzG3iRrMrbNLsELCRGLmU3zXIgxsQs24u0Rh+BMBPfbifX6JSaUJTIRrA5Ezfd8cuqkDsggX8rvmK6oOyhTWvxEQN6jmgWX6ahhFstcCBp87l6D6C8pxvNqy4SPlBU7YLURFggeEGDUjpNZBxs6bCSTcOloKGyRNG6peg2MxM1Ohing9Y615QsXGUwq0emQi5Dx9rhKxjF32Z3sRHfw+x4bAwZo7wMLqUp00w+0foiDZOBafmCOqKuTOQOfMr1RWfA/6JJstyUCxQGxLdbuQCVaIkS4d0nw+z/PN2s+kHVO8ozMvyR+lXYV9Dh9f0ljd/sgPS K97WQ20N oFXP4SNUap29PWdxHgZWZuq+tUqzi2gGsbvvSm3zAT4YU19IggF/BjiPGJAnWhZJHDZjqXiKqxGQ5ioWTdFz0pnXbKXTtGWKVe5f7y9RuASn3fKsUJhQBu1NuqQ== 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. Suren, would you mind dropping this into your benchmarking setup and seeing if these relatively minor additions make a difference? 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(-)