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 DFC57ECAAD3 for ; Thu, 1 Sep 2022 23:26:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A55380081; Thu, 1 Sep 2022 19:26:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62E0D8000D; Thu, 1 Sep 2022 19:26:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D01680081; Thu, 1 Sep 2022 19:26:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 36FD88000D for ; Thu, 1 Sep 2022 19:26:32 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 0CDF5A9FD1 for ; Thu, 1 Sep 2022 23:26:32 +0000 (UTC) X-FDA: 79865103024.30.CFD1FB8 Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by imf28.hostedemail.com (Postfix) with ESMTP id A5A04C006E for ; Thu, 1 Sep 2022 23:26:31 +0000 (UTC) Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-33dba2693d0so1890937b3.12 for ; Thu, 01 Sep 2022 16:26:31 -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=MTexhQmqymGfgaxSOwwhDwyp4l4FCh8W15KC6mgK2Nc=; b=R2o6wZ8rHFTrHg65HWm+sx7byON9XQMo2S9w2qAr7v877njUCnx965lCh5TDybN3fG szmKzMNl71kGYs2aeFk6xjyeuwbcVXFkgv5zAw3bvGqos+UnSn816jqobAwL2+pCKfzT W/26u7xLOQdtA3Iw5anxeOSG5ErmbCcWCr5YsjjqabfauOlrQtzEGoFnvplqQCIdYxIL JHJRAAIhmj8btwRvGxQl9ZtbveVvnZGjC/uV9Rjf9ChCAajmCvS7vnrSasRk1z2iew0z pngvq428HmyvaCXLmHtMjuform5IaN6EQQhsiphDW/8GvGNJPFbKid2FCogV2++SPCK8 Dr8g== 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=MTexhQmqymGfgaxSOwwhDwyp4l4FCh8W15KC6mgK2Nc=; b=vzCINEkgrahWL29l+oDVJH5hQf+OPrUv55t+Ies+yT8+d5TukhszcxpRJM06eJ7mUL FoY/sGvKc492gBNb6jdrQ51/+IuNS1VJuwP+QjVdGowpeeBqxhVRF2Zl1AJcfPqDPLOw Zbibl8KhYkEP63NJC80Cr/LJVEO1HJAGun83cME3g5PNPfRcD/8qdIpj8KkQhMtNfFna /jfhLCbVYBbXcGleKOkSLqjA1ejT7tZVUwOuPNLhaWRWf3qZ/GTgdr2vSOwBHrcUBoK9 7XYztzZz+PpJhs2okePqEVjZ2hgoE3JXrrLFPHjBmOjHUslrSjtniaQ3fI7IBaqSc62B XJBQ== X-Gm-Message-State: ACgBeo2X1WYq1IRCg1ZEfW1va/jqKDCYnkfQGB8vcRgc1hSINXyHJTmR czuM0otvPbdUUR2cg65QXxXIxIrq+livCP4mef1qUQ== X-Google-Smtp-Source: AA6agR7ryflRVLt0ycp3Tc1PbYwVBnDj1avkVAWAyik3VlypjQVDlR3+/VVpBD5mYLXhgprc+mz5ihSb0hJesE8YyOE= X-Received: by 2002:a0d:e7c3:0:b0:344:8cee:c384 with SMTP id q186-20020a0de7c3000000b003448ceec384mr4260095ywe.514.1662074790746; Thu, 01 Sep 2022 16:26:30 -0700 (PDT) MIME-Version: 1.0 References: <20220901173516.702122-1-surenb@google.com> <20220901205819.emxnnschszqv4ahy@moria.home.lan> In-Reply-To: <20220901205819.emxnnschszqv4ahy@moria.home.lan> From: Suren Baghdasaryan Date: Thu, 1 Sep 2022 16:26:19 -0700 Message-ID: Subject: Re: [RFC PATCH RESEND 00/28] per-VMA locks proposal To: Kent Overstreet Cc: Andrew Morton , Michel Lespinasse , Jerome Glisse , Michal Hocko , Vlastimil Babka , 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 , bigeasy@linutronix.de, 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662074791; 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=MTexhQmqymGfgaxSOwwhDwyp4l4FCh8W15KC6mgK2Nc=; b=P+Ki9jV+pbxJH4KhlFQkSNV4A9XUsixpjxddtb5pomyKzwuK0gsTs61CmNLwEMCAZroKpb j+u0E2MTi/oKnNwTtpQ1BCVHYwBj2uXuZ2FcP9mwf/y+hsPH3v+xugFwNJpEyiNjBWoR4W QTuBzA3k40UUVHeScGzjnfl/bXek+ME= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=R2o6wZ8r; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662074791; a=rsa-sha256; cv=none; b=1HBkXVuI0V7r8qfh+vWIbSKW5L5L9XTjcFPg6G4CohEetjuN7VMtQmM1IfaZ3STc1vz5sg yH/vMBJt3vS9KrY/9j8Vb35WvgBGO6AY8M2fLy64aKR2136feBc8pm8WJiwLrw1zZAblCg Hiifk3f4NPn1whc8wpfMtwd0n/a0agk= Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=R2o6wZ8r; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam11 X-Stat-Signature: 33dgpafcij8ame151an4u3zteypseygb X-Rspamd-Queue-Id: A5A04C006E X-Rspam-User: X-HE-Tag: 1662074791-855161 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 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 with > > suggestion that =E2=80=9Ca reader/writer semaphore could be put into th= e 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.=E2=80=9D 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 wa= y > > 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 d= oing > 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 caller > already took or is taking the lock and this function is just marking t= hat > we're holding the lock, but it's really taking a different type of loc= k. 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'm open to name suggestions but vma_lock_multiple() is a bit confusing to me. Will wait for more suggestions. > > - I don't like the #ifdef and the separate fallback path in the fault ha= ndlers. > > 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. I think it can be done but would come with additional complexity. I was really trying to keep things as simple as possible after SPF got shot down on the grounds of complexity. I hope to start simple and improve only when necessary.