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 492ECC07E9D for ; Wed, 28 Sep 2022 02:28:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60FB28E0116; Tue, 27 Sep 2022 22:28:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 598F78E00C1; Tue, 27 Sep 2022 22:28:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EA3E8E0116; Tue, 27 Sep 2022 22:28:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 281F48E00C1 for ; Tue, 27 Sep 2022 22:28:55 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EB04E1607AA for ; Wed, 28 Sep 2022 02:28:54 +0000 (UTC) X-FDA: 79959911388.21.2B65AB9 Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com [209.85.128.181]) by imf16.hostedemail.com (Postfix) with ESMTP id 90720180007 for ; Wed, 28 Sep 2022 02:28:54 +0000 (UTC) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-349c4310cf7so117828127b3.3 for ; Tue, 27 Sep 2022 19:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=Z0+bMELpdKdE8Q7V1g1xJPLf4JnpkgWuSB4HVsFpACw=; b=r3bKcW8YDyjLKKVV2T2nu9EK+l6skZKjuSXHqw1h7QSsCWuzjJLZSSPbPLqCkYLzuE srxL4E7bdabGQ54uivxtXo6aVslalhWzKnRB3ME9ODMXpkyi1jEarxBh3NdA34ePCygI 1Lr3QhYYbCrQxYg+RD5l5rVH3u4LZRTUbQOjBHMe6Udu2afMMcUdFBQFGDW0FxigAg8O XPKvUjM4Q/CEzJnptfAVyGJG2I2t7f4KgpKYO65hCzHnmx7eNrxdV39FhGX4toQIRrGb 38ZkEbv55Ye2BtH0b1tKVQ30lEB+ClAg4hKd3nwJkVNLlBsG6At6ipXEoz4LKLfj6HTS GbLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=Z0+bMELpdKdE8Q7V1g1xJPLf4JnpkgWuSB4HVsFpACw=; b=6C9XRTYMHbq8s+f4ULbvF3AaWa/afsjqjc8ozuZWdodB5xHWPFTn7K0nCWFF837H7L wn9GD1ea0yFK711p3yk4/cqPsENtkVuVwYEwYf/1TpsAVkDvbsHW0HwNfAVYUb7NwhZB boQV0q+S1FcKf8y98hPL/pNndm+3tsayQ4F421vQVDwJAmxMlXRiyAEC3nD1k2TfET+5 t5gFsZn0AvmtRxKX+UqWcpW7QlaGE29A9MnVMzG2t8Bk7dglrLSSMYlLgLWq6oWtqU9X lWAGNGuUV/anIIfQgTXOj+rCj+G9Jjkggsh8VWVlMRrlMKsKlJ2CH8T5XlxZvRJAd5L+ bBSA== X-Gm-Message-State: ACrzQf1Rn06pxFHjl4Ew1TESfn8kHdE6MGJZ3RwZjb3EZ4Dk3HSBH4eL Y2q8B4netnCSluct6amBCvdQdZRIn4S8W6G6seGBIA== X-Google-Smtp-Source: AMsMyM7cKmM6s5Wj2EGqGts0HQF0PxKwiB/suSdXFthaiHYdD52M0dUUPdTaFJmVGmtRhNHzLoZ6tTNAnTCaRpIdjiM= X-Received: by 2002:a0d:ef84:0:b0:352:9e0d:a596 with SMTP id y126-20020a0def84000000b003529e0da596mr3923448ywe.347.1664332133583; Tue, 27 Sep 2022 19:28:53 -0700 (PDT) MIME-Version: 1.0 References: <20220901173516.702122-1-surenb@google.com> <20220901205819.emxnnschszqv4ahy@moria.home.lan> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 27 Sep 2022 19:28:42 -0700 Message-ID: Subject: Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal To: Vlastimil Babka Cc: Kent Overstreet , Andrew Morton , Michel Lespinasse , Jerome Glisse , Michal Hocko , Johannes Weiner , Mel Gorman , Davidlohr Bueso , Matthew Wilcox , "Liam R. Howlett" , Peter Zijlstra , Laurent Dufour , Laurent Dufour , "Paul E . McKenney" , Andy Lutomirski , Song Liu , Peter Xu , David Hildenbrand , dhowells@redhat.com, Hugh Dickins , Sebastian Andrzej Siewior , David Rientjes , Axel Rasmussen , Joel Fernandes , Minchan Kim , kernel-team , linux-mm , linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664332134; a=rsa-sha256; cv=none; b=JVrO+L76d65opdWZxutfuqDGqrapDlAcH9sjBJTB+zoA2znUk6HRB1hgRYMORaTi3hKPcE UgKusuFPSKT2s2Z201Xi6Z/boaQde6isKMs1ipfYkzbjOeDZZT5XsyuuzcZ5VVfHh0fzup 0XfUrUCuepF1vmtmdoI/4hIEZePSzng= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=r3bKcW8Y; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664332134; 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=Z0+bMELpdKdE8Q7V1g1xJPLf4JnpkgWuSB4HVsFpACw=; b=72Q/itisKaPfsTUaHoMkzMaocBcZvCwRNS/o7HWc6hBbyXFD5iy0n0o82RgKVi125rrlej lMkFKPZC/8GCvnkzu45C5Hpr63g3x+e4bESzZ+1vIU//CCCUkuZiuEngncsogClxy7Qa/P FRUmv6/WNk3UJZJmDe+RF4KLSunXdWw= X-Stat-Signature: oqowypykqd6is3xyrdwxsfyth31ghu4q X-Rspamd-Queue-Id: 90720180007 X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=r3bKcW8Y; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.128.181 as permitted sender) smtp.mailfrom=surenb@google.com X-Rspamd-Server: rspam11 X-HE-Tag: 1664332134-715368 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 Sun, Sep 11, 2022 at 2:35 AM Vlastimil Babka wrote: > > On 9/2/22 01:26, Suren Baghdasaryan wrote: > > On Thu, Sep 1, 2022 at 1:58 PM Kent Overstreet > > wrote: > >> > >> 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 w= ith > >> > suggestion that =E2=80=9Ca reader/writer semaphore could be put into= the VMA > >> > itself; that would have the effect of using the VMA as a sort of ran= ge > >> > lock. There would still be contention at the VMA level, but it would= be an > >> > improvement.=E2=80=9D This patchset implements this suggested approa= ch. > >> > > >> > When handling page faults we lookup the VMA that contains the faulti= ng > >> > 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 situat= ion. > >> > > >> > One notable way the implementation deviates from the proposal is the= way > >> > VMAs are marked as locked. Because during some of mm updates multipl= e > >> > 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 lo= cks > >> > and other complications would make the code more complex. Therefore = we > >> > provide a way to "mark" VMAs as locked and then unmark all locked VM= As > >> > 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 wh= en > >> > 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 th= e > >> > 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. > > > > Thanks for reviewing it! > > > >> > >> Two complaints so far: > >> - I don't like the vma_mark_locked() name. To me it says that the cal= ler > >> already took or is taking the lock and this function is just markin= g 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 s= ay that. > >> > >> This is AFAIK a new concept, not sure I'm going to have anything go= od either, > >> but perhaps vma_lock_multiple()? > > > > I'm open to name suggestions but vma_lock_multiple() is a bit > > confusing to me. Will wait for more suggestions. > > Well, it does act like a vma_write_lock(), no? So why not that name. The > checking function for it is even called vma_assert_write_locked(). > > We just don't provide a single vma_write_unlock(), but a > vma_mark_unlocked_all(), that could be instead named e.g. > vma_write_unlock_all(). > But it's called on a mm, so maybe e.g. mm_vma_write_unlock_all()? Thank you for your suggestions, Vlastimil! vma_write_lock() sounds good to me. For vma_mark_unlocked_all() replacement, I would prefer vma_write_unlock_all() which keeps the vma_write_XXX naming pattern to indicate that these are operating on the same locks. If the fact that it accepts mm_struct as a parameter is an issue then maybe vma_write_unlock_mm() ? > >