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 31957C47DA9 for ; Mon, 29 Jan 2024 21:58:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7798B6B0071; Mon, 29 Jan 2024 16:58:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 728BD6B0093; Mon, 29 Jan 2024 16:58:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CB266B0072; Mon, 29 Jan 2024 16:58:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 44EE66B0093 for ; Mon, 29 Jan 2024 16:58:18 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C213FC0A78 for ; Mon, 29 Jan 2024 21:58:17 +0000 (UTC) X-FDA: 81733712634.18.CF5EE98 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by imf22.hostedemail.com (Postfix) with ESMTP id DD066C0020 for ; Mon, 29 Jan 2024 21:58:14 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=oOh4LSwJ; spf=pass (imf22.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=lokeshgidra@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706565495; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=CUG0VAx6fB3sqRZQjRRGH6lMhLjFI7rY91Z4hSbS8UE=; b=0zD450zT+XdzD1n6XOuU19Qoe6UKrBrUDlLRMcqd2IyuI85+SmQO/tPQFzX12xwpTCuMiV C/jBlEd1GfrVwZe7RE9r63k4JIdpY6HLOxTJfoHdwfFHkZ3iIAHBxJ2wbMHQG9sBKPvqeN T3/uI8WrQeOe33AEH8LsxL1WnyHxEKo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706565495; a=rsa-sha256; cv=none; b=cl5FD2TyZXR/ZEZCyCHnL4EGq+3p07OxAt74xKeHoSm6jx6mzTRkzcdczQPyzyDWF6XGCv CGAhMQ4fwD8bKpeIETMaeZxWWMNf3eP6XyFwRnBt2a6ZqdZ4wre6MpGsPqZV7usKix+Q4m LrWncon040+IlZ72i4sh4WtJ88U7tPo= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=oOh4LSwJ; spf=pass (imf22.hostedemail.com: domain of lokeshgidra@google.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=lokeshgidra@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-33ae6dfa923so1275622f8f.1 for ; Mon, 29 Jan 2024 13:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706565493; x=1707170293; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=CUG0VAx6fB3sqRZQjRRGH6lMhLjFI7rY91Z4hSbS8UE=; b=oOh4LSwJKA3CMtAeHt5D0whG0gF/sV7NJZHfOe9HfKtP3dzmjCRTQ7LYm3Q8S2ViCv rhbtOEfz6CHR4c6eMp6/CpLsvyypC9whGOyFABDFueSbViQJXRQNFssxHGF8UXMno/MH Ti9yrOG1lMK9Lu9THt6FnRK4Sk+0bsHF+J6fKbjemo4mip2peXUJqv7nf0dADjyS/gly eCahfCF143W5Kmam/MYGeDdH99iFUQDAJmVRQUZm9EXJTIRN/V9S+HzkeLfD0btjYfVB z2hHsqq8Wyxa5IlVonLYHH0+ArrXZG66M61ZIYhNQ22IGBJiQL+3Bg4pn9/Blfxal2cm lwvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706565493; x=1707170293; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=CUG0VAx6fB3sqRZQjRRGH6lMhLjFI7rY91Z4hSbS8UE=; b=jGnfD9iuetAS9GajmPRCL9TwOBRf3Ekq1ZWPp6ZuuhDUAp6Oy8Pn/ZLKEv7Nb42sXg v9eHOryCfZOjb2VXprZnC0tzUkVwG1J5Z5ctRvEgFVQen0yvdUfIeYequFLaRLqlexyS IgqC3UlcbcSYoMQ2CKUSDkJc/JYkVYXN0cQImBZFg/gZsF37ZdlhjHePa67dq98Oy1R1 rjKHVpjMp7FsjToX4VFTqZsu2K3xtWB8gokykhP8ssiPcgTDCB6s7T5UxrCh8m8avcwk A18egXz5wNB0WQ+b1gf2FBomZcoI8nCPy1quyj26/o26G0ZlnecgTB3WD9NHju+q6BY5 UzDw== X-Gm-Message-State: AOJu0YyptCDxUn3c7Mz6chDPPkyFt9clhS0TmgiTuiJw5lHX+/dEmNDE 0O3SQQb1SRPybX96jMgKbeo8W7wXRW3axXg/k91ymyPAhOp4GTMCmpQ34oCHuO4bcwSJSV6O43c md7q/F+wNPjjUkoWR0tHn59CDB2EWSk4ZqzXL X-Google-Smtp-Source: AGHT+IEEO9aGC7CpGPiSuiXN+SuE0N37YyaPf1+lp1ZQZTirO7MY/Cp5QyQH6Dgc3eP4RAbyZkoXfbiAF1yqBSVoK0s= X-Received: by 2002:adf:e44a:0:b0:33a:e5a8:eaed with SMTP id t10-20020adfe44a000000b0033ae5a8eaedmr4230312wrm.14.1706565493189; Mon, 29 Jan 2024 13:58:13 -0800 (PST) MIME-Version: 1.0 References: <20240129193512.123145-1-lokeshgidra@google.com> <20240129203904.7dcugltsjajldlea@revolver> In-Reply-To: <20240129203904.7dcugltsjajldlea@revolver> From: Lokesh Gidra Date: Mon, 29 Jan 2024 13:58:00 -0800 Message-ID: Subject: Re: [PATCH v2 0/3] per-vma locks in userfaultfd To: "Liam R. Howlett" , Lokesh Gidra , akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, selinux@vger.kernel.org, surenb@google.com, kernel-team@android.com, aarcange@redhat.com, peterx@redhat.com, david@redhat.com, axelrasmussen@google.com, bgeffon@google.com, willy@infradead.org, jannh@google.com, kaleshsingh@google.com, ngeoffray@google.com, timmurray@google.com, rppt@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: DD066C0020 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: cdq6s7of5nm4h1hdy1trwsz87w9iti84 X-HE-Tag: 1706565494-756077 X-HE-Meta: U2FsdGVkX19YNe5Pjiq3sNoWsUbovcpfLHUmY+YKFSrrplhGH1t+SAt3s6bPeWLMLGMSQawNP1izm2c75vN1sPHABP6cRPivHwpB3BQYUpBWdhuJOQXN2NqoWlGyJT0qUAyded0gXdm1GKsaYc3IXhkS3X0bqmdEjI+/WclN8/wOdrWMan1C5UyzZpe21Rs/+qsCYuOD2pOEdqkUCqobx/EnqL2vEOUz8aWEYw/xwRM/AMOrq96abvF1kNO9jNBb6pWr3Yr06Bvc0bQFq3QBQu5wUDzPdqrg6sNVii5t0ZeW2vROJdE9iPMVw7QNZL9XMVoCrM7c5yGncryvNscyN5P5w6x64pPR2K+BWrR62vkvw1U0Hfu7n/kQv0jd0vzw6wTq2eHaKcdeMAsndVJ0eiTxfQeCurs/ylvOy2yyMLAYi3w7J7DH0idURV9s9zqJvOYF2nxSYt91PBJencknLiD57G4cEOoNNnaf3co9+cZlUjV6siIs0sAF0yg7KqfeIAq3gZIe+0lG/2mGbHpjIHpt3NyFMQUzprLtsDIXRGFhHFd940ISTT/Bmi5u7Vhm2sVx4De/H/z0e+EM/kvrrT9dV276CWD9xjCohqaBcQnAj98CSyZ8iDo6akbjq3JEK0kV+9VI2p2w8b3+m9zF4gLwslPQKKoyDzg7/PhS08O4uozThXC+4w3k+5SwZ+hxB7qAnZEhsSK+yGqYBIIQlarHSyReTyrPZrJlsZV6TWm+M50khnN+cuFTDqrG0wmIxnRdQ28ZlJX5ddJ7jBC8yUEmdEeZJShdtLIw5Bj5llG/yJdKe5Xce8VvTG2WN+9WvIgw+bU2gbIhZe2YfRA2J/tcw/nwMpJlKE7LxiClnK3s2GokuXbDx+IwgEkrf09WTX88MiK+RohDAdm6EvtHi1gvtenoA/r57NG1AzBRIixID9VlRTI1OQby3SRetLQ8P2uCRg+ioX6b0t9xTG6 6nC+Ofk2 qeqxk/5XXuuxa9oXAnOwNMnJX7x4ncQzDijtNISFurgi8y5cikbMmJtC+Ys982S9zRmjj+nkDXmPsTCaS4d+W3u8Vet/FWt7ZfBO3Ztv7N7qVw8V/WUVkXMjvkRaw/PMAEX1Ozfu7G7j6rlglro8RU9gnRQbfhlvDSEUos66fgR/NMEtEFVeoWHjcwnAN/1hLdLmMk9U8qPizVv1ipdkKCbO8hisn2vs3sHN1+JcHlpVlSMfL19c+tZc+j4TcD/VjTfA2bJzGuiRdRUm0ZtMYCCb8Ny/y4bSLZ3JO7GfxPlTHC7eBLY0Z8YgheNfDj2z9tLeoJHG/d4+sBrU= 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: List-Subscribe: List-Unsubscribe: On Mon, Jan 29, 2024 at 12:39=E2=80=AFPM Liam R. Howlett wrote: > > * Lokesh Gidra [240129 14:35]: > > Performing userfaultfd operations (like copy/move etc.) in critical > > section of mmap_lock (read-mode) causes significant contention on the > > lock when operations requiring the lock in write-mode are taking place > > concurrently. We can use per-vma locks instead to significantly reduce > > the contention issue. > > Is this really an issue? I'm surprised so much userfaultfd work is > happening to create contention. Can you share some numbers and how your > patch set changes the performance? > In Android we are using userfaultfd for Android Runtime's GC compaction. mmap-lock (write-mode) operations like mmap/munmap/mlock happening simultaneously elsewhere in the process caused significant contention. Of course, this doesn't happen during every compaction, but whenever it does it leads to a jittery experience for the user. During one such reproducible scenario, we observed the following improvements with this patch-set: - Wall clock time of compaction phase came down from ~3s to less than 500ms - Uninterruptible sleep time (across all threads in the process) was ~10ms (none was in mmap_lock) during compaction, instead of >20s I will add these numbers in the cover letter in the next version of this patchset. > > > > Changes since v1 [1]: > > - rebase patches on 'mm-unstable' branch > > > > [1] https://lore.kernel.org/all/20240126182647.2748949-1-lokeshgidra@go= ogle.com/ > > > > Lokesh Gidra (3): > > userfaultfd: move userfaultfd_ctx struct to header file > > userfaultfd: protect mmap_changing with rw_sem in userfaulfd_ctx > > userfaultfd: use per-vma locks in userfaultfd operations > > > > fs/userfaultfd.c | 86 ++++--------- > > include/linux/userfaultfd_k.h | 75 ++++++++--- > > mm/userfaultfd.c | 229 ++++++++++++++++++++++------------ > > 3 files changed, 229 insertions(+), 161 deletions(-) > > > > -- > > 2.43.0.429.g432eaa2c6b-goog > > > >