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 A05B7C02182 for ; Thu, 23 Jan 2025 17:14:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1E3B06B0095; Thu, 23 Jan 2025 12:14:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1936A6B00A1; Thu, 23 Jan 2025 12:14:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0824D6B00A3; Thu, 23 Jan 2025 12:14:53 -0500 (EST) 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 D6FA76B0095 for ; Thu, 23 Jan 2025 12:14:52 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8557FAF29B for ; Thu, 23 Jan 2025 17:14:52 +0000 (UTC) X-FDA: 83039366424.15.C026DB6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 72339180009 for ; Thu, 23 Jan 2025 17:14:48 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=uTi3bxKR; spf=none (imf24.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=1737652490; 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=4yAoXigjcz2L5cxtqIhHEfwMwo3R7mjfNXoSQXTLRAw=; b=EBGzJvCDN4XTGPlF43Sk02XN8Ks6uC50HUHLu5szVLwbqjHWSG+JXCO5E3A71Nm0phEtts imxSou+ShJ0sHb/WDcWOeXfkFLM7Ywo9H48QDO0BjBpoNRMkUz36w1MLr4LKpZEM5M27Gq uo5mNDVPZNzxh6xOb13E8+42v9xSl0I= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=uTi3bxKR; spf=none (imf24.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=1737652490; a=rsa-sha256; cv=none; b=yIa3Co7/6vmyswVA1kJurlKZCNN8MN+fJgxMrXUyytissxi8KXetIh6H8K8wkoIhCIlCDf 99QDH3DmXlIxhIN63t5cehmKBCIRFRDjyGzDCDffVHD57xufD9YTyiwPhiB1i6DLXMZQa9 USeyGuuBnheqye0B+JNfdtkguNhC/eE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=4yAoXigjcz2L5cxtqIhHEfwMwo3R7mjfNXoSQXTLRAw=; b=uTi3bxKRULONszWQeWtiZxnMAL qLjg2fkjP8Yi9DwJs2HUNR2KqVIgSREi9hl2XrkTVsRNadHVMipgBCzUFVZfBSwcD5UX9WlzeRttK G7eDWbQPhjJK+62269VuGtzerAPJ4Ts+0GrOVl1Yix1g7hHpUdXRTmM/uTcFhklY3DMxx0LgHQLKk P3U/YEHzvu9sXjDHNbH+f2HMBQ5xoXaDLtvJ1PY3nidjQD+L22FR8HTm4mpeOatQ10+q0pJwSibWF Y1PK1f5k1XjSy+1bFYcUvw7JcRiR7zLfRQi9+GgTOMgTRXE66vkwBGJtQn4QUZESKiwNhmqMA+Jc7 lhOSn4uw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tb0mu-00000009XAj-0bAJ; Thu, 23 Jan 2025 17:14:40 +0000 Date: Thu, 23 Jan 2025 17:14:39 +0000 From: Matthew Wilcox To: Barry Song <21cnbao@gmail.com> Cc: lokeshgidra@google.com, Liam.Howlett@oracle.com, aarcange@redhat.com, akpm@linux-foundation.org, axelrasmussen@google.com, bgeffon@google.com, david@redhat.com, jannh@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ngeoffray@google.com, peterx@redhat.com, rppt@kernel.org, ryan.roberts@arm.com, selinux@vger.kernel.org, surenb@google.com, timmurray@google.com Subject: Re: [PATCH v7 4/4] userfaultfd: use per-vma locks in userfaultfd operations Message-ID: References: <20240215182756.3448972-5-lokeshgidra@google.com> <20250123041427.1987-1-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250123041427.1987-1-21cnbao@gmail.com> X-Rspamd-Queue-Id: 72339180009 X-Stat-Signature: azdnhm1u3fgwxqpau1ru9i9rur68xbyt X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1737652488-691018 X-HE-Meta: U2FsdGVkX19UiuvxxBk5zb+EW2QMO1aOsyLCD7T1CnkGBwXolukqgwOBtlTUxcj0N5OdCdWV4HlZl9hNZ4gTAl+AVA4bIM+aXL6Jexr9JDfxbwNUU7VESaQisMENqeBz9RcUCiP9RvKTRwX4gpn8kBnU/DUtmpRpqFtYlycFq+1sfTJc2WWo8oDcM7r8MXCdi3UKDPCLOZL5ffqR2QTsKcglGIJKSz+KlMlSN91DrPr2WFfHScY6YbOwDswfl6JcCtmOz4sbvflQ8ZKYBcDKzePr3Xr3Wa7JsIGOMyVjN/YfMpD5JhA4iDFSPc65TQrSoNP8j0mgbSYlZmj40PeK3W9HEcWqZ40snLPKOcOKEq3mWpXBxHnxCZzxmiWV/60HAb1/sBrd72msVvGdM1lviFwQHCKnZ5+QhF4GAVguKx1GGtMxVRMmS0KuUpjtPXOQjG+ZN40fTIGs29zoO3IiSTQJjCGnYqfM7CLJo0zB19XeKZ/3hxDn/7vbuhowCwKFe1s1JduSkjdmkDEVdg1RHxiVOdlWk+7sDrND4NgfUQ5p70DGAvYFGjj56HCwRKgfjNnnlmvjkVlLM9+Q2642ER8g7er43TfiNKJThllyF3UOG+4C0TCEERTMujP6yGaUsIzouey/Tne3alGMlSqhIwT9NammfijfrzR6Upuf4qzF6G7N+nY/OEZyc4SsmvciqgDS6cdmH2tOlrJAbN0yFtbOtVVQASS2kR+TQwT9aJFENcq7gYrTOQI0D2hlRrJsQ5EpNtVX3A7Cm8Ld3X9hWATYHFiIvVcy2h2Bfh0hKu1BhicrapljfvrMGKXxhNuMrzSzSNbzl9ILduvY0Fh+MWq701zpsVuutFX7cGsKpWCdtBhPS+dApkXvfVaLNGdAf3jOfB6RYqYqb0hCvFq4plDH6rK58sHv9yKHf2qzfVau/UiaG/Y4lyIOuE4oL3YGf+a3BqzeFd3Cdgs8mL0 8cbPngrD 8ZTWItwzV0WE5KiDyxZc3Iqv5EDgYHuUcE3McGEsvwICd+zOnem7WvKyWmkJ8GgMsKjJHryv/fGpvg7uuoN3/R5K8OWsv0yyKPhVmDDAhORS01Ro47CCK8KzQXAvpa42ZOqcvBjX1gQd36pkt+IUUxXEZuKb7I+ZGT4KlowJ7G3BL2ygpQTBp0clhEOEnPoPZaS08TEFOr3k3RoOWvrhZz994B79jntbFyuJm6T+XSbJ0pupUZICEpWV8a8lqI9goYmPp/r9+qWKJ0kvg1CWHxL+CYhzNScWLh76H4AaG2Zc00dxjMvk+1mDYzA== 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 Thu, Jan 23, 2025 at 05:14:27PM +1300, Barry Song wrote: > However, we’ve noticed that userfaultfd still remains one of the largest users > of mmap_lock for write operations, with the other—binder—having been recently > addressed by Carlos Llamas's "binder: faster page installations" series: > > https://lore.kernel.org/lkml/20241203215452.2820071-1-cmllamas@google.com/ > > The HeapTaskDaemon(Java GC) might frequently perform userfaultfd_register() > and userfaultfd_unregister() operations, both of which require the mmap_lock > in write mode to either split or merge VMAs. Since HeapTaskDaemon is a I don't think that's an innate necessity. It does require quite some work in order to fix it though. Since it was so much work, nobody's been motivated to fix it ... but now you are! Congratulations ;-) The reason we need the mmap_lock in write mode is that the VMA tree is currently protected by that mmap_lock. It shouldn't be. Logically, it should be protected by the ma_lock spinlock. But today we use external locking (ie the mmap_lock) because fixing that was a huge amount of work that we didn't have time to do. This MAP_VOLATILE idea is never going to fly.