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 976DDECAAD3 for ; Thu, 1 Sep 2022 20:58:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29F6980054; Thu, 1 Sep 2022 16:58:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24F9B8000D; Thu, 1 Sep 2022 16:58:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1175480054; Thu, 1 Sep 2022 16:58:32 -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 F31D78000D for ; Thu, 1 Sep 2022 16:58:31 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AB237C112D for ; Thu, 1 Sep 2022 20:58:31 +0000 (UTC) X-FDA: 79864730022.20.7FCDFD6 Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by imf20.hostedemail.com (Postfix) with ESMTP id ECFEF1C005C for ; Thu, 1 Sep 2022 20:58:30 +0000 (UTC) Date: Thu, 1 Sep 2022 16:58:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1662065909; h=from:from: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; bh=4hkUsmhoc/mtitBsMEKBISOd/1pAkSpFc2P/cfXQtjM=; b=GBx/osHm3HGi4Ds4wKNlfh+0rOeAjSc5fMxjCY9+prDg46Our7ah2+T4UCkEyoyjGAR3Ey DNyFdaH7yElNXaYOG7p+DGMlnJB29QeQAVtRk4yNGTDim3sXPR4Q5JwB92gpqpAdtQY8uE Z2Ok6tGIN+Dib9yzL+1nMDwaoBKyC1E= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, kernel-team@android.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal Message-ID: <20220901205819.emxnnschszqv4ahy@moria.home.lan> References: <20220901173516.702122-1-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220901173516.702122-1-surenb@google.com> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662065911; 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=4hkUsmhoc/mtitBsMEKBISOd/1pAkSpFc2P/cfXQtjM=; b=L5jaoMgJLgp2U7PcpjYkNfuFH1IuGYA3pNmX0x1zyBAwvXoVA+yzpkQGpWyTllRwn04CXg Rz9LVvY705Qu14iy4GGye21FHBPGxIZyHG6CbBS8iKb1gPanfa6H7F5ORS9rWfZFig00+i 1Vs0BrqteW/wJUMwrPwYIqUwH1FD4h8= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="GBx/osHm"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf20.hostedemail.com: domain of kent.overstreet@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662065911; a=rsa-sha256; cv=none; b=NqSBo+3uQ+L5Fi5fzPobvya2/qWAemm6cd+fONFb2UD6wXZW9uyv0VBq3u/wWgwKZj+0Hz ihv1H9qiH4RK0rhJjVln/G1p/9ktBVknv6HWL6BGqlMoiqkqlffd0Y450H8DZAY7/gJnva 6ABiHhMJ2d5LZFX+4CEsOY94NMZSGCk= Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="GBx/osHm"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf20.hostedemail.com: domain of kent.overstreet@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev X-Rspamd-Queue-Id: ECFEF1C005C X-Stat-Signature: a89xaxpu1kh3944ox34rwnor9be3d967 X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1662065910-157969 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 Thu, Sep 01, 2022 at 10:34:48AM -0700, Suren Baghdasaryan wrote: > Resending to fix the issue with the In-Reply-To tag in the original > submission at [4]. > > This is a proof of concept for per-vma locks idea that was discussed > during SPF [1] discussion at LSF/MM this year [2], which concluded with > suggestion that “a reader/writer semaphore could be put into the VMA > itself; that would have the effect of using the VMA as a sort of range > lock. There would still be contention at the VMA level, but it would be an > improvement.” This patchset implements this suggested approach. > > When handling page faults we lookup the VMA that contains the faulting > page under RCU protection and try to acquire its lock. If that fails we > fall back to using mmap_lock, similar to how SPF handled this situation. > > One notable way the implementation deviates from the proposal is the way > VMAs are marked as locked. Because during some of mm updates multiple > VMAs need to be locked until the end of the update (e.g. vma_merge, > split_vma, etc). Tracking all the locked VMAs, avoiding recursive locks > and other complications would make the code more complex. Therefore we > provide a way to "mark" VMAs as locked and then unmark all locked VMAs > all at once. This is done using two sequence numbers - one in the > vm_area_struct and one in the mm_struct. VMA is considered locked when > these sequence numbers are equal. To mark a VMA as locked we set the > sequence number in vm_area_struct to be equal to the sequence number > in mm_struct. To unlock all VMAs we increment mm_struct's seq number. > This allows for an efficient way to track locked VMAs and to drop the > locks on all VMAs at the end of the update. I like it - the sequence numbers are a stroke of genuius. For what it's doing the patchset seems almost small. Two complaints so far: - I don't like the vma_mark_locked() name. To me it says that the caller already took or is taking the lock and this function is just marking that we're holding the lock, but it's really taking a different type of lock. But this function can block, it really is taking a lock, so it should say that. This is AFAIK a new concept, not sure I'm going to have anything good either, but perhaps vma_lock_multiple()? - I don't like the #ifdef and the separate fallback path in the fault handlers. Can we make find_and_lock_anon_vma() do the right thing, and not fail unless e.g. there isn't a vma at that address? Just have it wait for vm_lock_seq to change and then retry if needed.