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 D8A57C02180 for ; Thu, 16 Jan 2025 01:41:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 654B16B007B; Wed, 15 Jan 2025 20:41:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 604AE6B0082; Wed, 15 Jan 2025 20:41:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A5866B0085; Wed, 15 Jan 2025 20:41:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 29FFA6B007B for ; Wed, 15 Jan 2025 20:41:44 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id AEAF0A051D for ; Thu, 16 Jan 2025 01:41:43 +0000 (UTC) X-FDA: 83011613286.08.7E4FD32 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by imf14.hostedemail.com (Postfix) with ESMTP id D296A100012 for ; Thu, 16 Jan 2025 01:41:41 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UpgKijlZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736991701; a=rsa-sha256; cv=none; b=5CTnkXvERYVBlSFlBYYyU6Dxcf9X3BveBWmhsLeOHyjqZuVnYcDfupjQIHFc53BOT7F17z TiyeIYH7FO75cdhnwrjkBqAvpUlwlC/sw4JljZnUqRhLB0jJjAaALwfd8MZRCz9XUdcbZ4 aiiVOmm6RrNbk/oIpsc1HTiFn+MKjF4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UpgKijlZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.160.175 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=1736991701; 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=i5qp4Kp9mAi9TjlMT6stn4fx5XakFjgS/5BnY6/8sIk=; b=qm2zaelkk4Z4Nzyu1LsLLCNusqK1CT/6/SET3P+S6tsyrSKiIJDCiQXFjx7GWO/SUC1pWg vSjrcw3PBsZL6SnHP45ou22oU3UgIxOeN3HiRZ+3qfcoy0uPbQN3SMhpYFa2yBIPPvil95 eLgXNGiDa97tjhAsWPla+97PuaJa0Mg= Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-4678c9310afso65281cf.1 for ; Wed, 15 Jan 2025 17:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736991701; x=1737596501; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=i5qp4Kp9mAi9TjlMT6stn4fx5XakFjgS/5BnY6/8sIk=; b=UpgKijlZnc0H+6JeCysR/quIZSoHXOz1fh5qqwrT2dp3CCnvAnyV76U3Xvpyrqobz0 MgkYSZ1psspGiu5SGWpNxvEa7zN+NMNBkiWsDcLdShDQKNdpiWXCPy6salG2RJoTVR+y c1dCyTOU7PHmfy1jrUHkhu0KMge3DAsDPT1A9LmXBoAbIQ1suiLYNZeU8u8eVcFNmyKL nAD85I/A8b79u4YNUZp7HROC3X+YzOXpjImZtobxBeyCitse+btw5gdh9P/D4m430l5O sY8yF/gryVI2XCq5Ok3rXs1WCO4VFo6xZ29AaHQg0TAUkH704HZ43cO/fLBtyL+qatM3 bnyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736991701; x=1737596501; 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:message-id:reply-to; bh=i5qp4Kp9mAi9TjlMT6stn4fx5XakFjgS/5BnY6/8sIk=; b=QuRxbt7K6c39VLmzL1GZDvVIahdeS8M+FChL/4J3aKo0UAd99d2cEUfJy0aPFA1Gwl FJjIafPfcdghXSWArwH50LFgeTXphi9kcwM72jq+tcR7lVQnbztfAYF0nflPRsCi9Di9 mYbr7zZyGba68/ggR+aCfvB0YxAy53DvpFHWaH3Aa13hB1G6FiKDoLs2udCVSyiMYiIZ JxHnwRukXJQvQ9H2sIXpGuDGIK5bp0JzVtLy1U6A7ovmqwARdAUSfU4RYedm9+7XZiDl U8jcFw3blrLmxWptKYFFRc1fuhNKFjDatyaaAQQMOrsGwW089gKQRYwqqvycyEcdtc/9 WL3Q== X-Forwarded-Encrypted: i=1; AJvYcCU+k0ovhWjBL73Cfm1lNyDx8TIup7ouL45ZbTDSoj6g/qsNLKgRuWAZyyTCQFVY10kviqsgAdAbtg==@kvack.org X-Gm-Message-State: AOJu0YwW8ffXajWtmt6RmjKd3erYrGIT2rnIoibPTDmafaNFMF8Y4BHm cnoMkgKrGDb0Z3Nuce/CM2Uks+a9x73ajNYPUm0TS98qUQr4Hc+IZJt6eVjSBHHShy84R26ncyv bml+F3Ry34jTuZ6IuHX6C0H0nrmiDCFUi82Dg X-Gm-Gg: ASbGncuga5PGB5wk7Kb9aVZh+JheKqoNJ8jpeM1viYi/G+NM/RaXNgD3NFLndFoTSwz 4zGSlgaX6mhrzdAvjK5819gFOgTIi9HR3ORxHEg== X-Google-Smtp-Source: AGHT+IHFjbHOfd9g4KoCVXGG8P/NJDkMykdB702IOlnovia7txfoXehQfUQdevoX4JoF6GQMGrRK9R8xH5pWaxkApJY= X-Received: by 2002:a05:622a:178b:b0:46d:f29d:4173 with SMTP id d75a77b69052e-46e04186a53mr1735031cf.16.1736991700645; Wed, 15 Jan 2025 17:41:40 -0800 (PST) MIME-Version: 1.0 References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-12-surenb@google.com> <20250115025830.pebmoyerkruqtx5y@master> <20250115120532.mgvjhcrzvmmjasv7@master> <20250116013747.akajp2kdwhmbgq5r@master> In-Reply-To: <20250116013747.akajp2kdwhmbgq5r@master> From: Suren Baghdasaryan Date: Wed, 15 Jan 2025 17:41:27 -0800 X-Gm-Features: AbW1kvaNN7I5SxVgl-wVj0Cuhtdomh1AvTxEkeyb7hxD46ZxXpRTqujEDsqVhdM Message-ID: Subject: Re: [PATCH v9 11/17] mm: replace vm_lock and detached flag with a reference count To: Wei Yang Cc: akpm@linux-foundation.org, peterz@infradead.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, david.laight.linux@gmail.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, lokeshgidra@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, klarasmodin@gmail.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: D296A100012 X-Rspamd-Server: rspam10 X-Stat-Signature: whzuimow9o84jumk14gcm7e1p6a4oyin X-HE-Tag: 1736991701-618895 X-HE-Meta: U2FsdGVkX198wChKlaE7kU2tyRxenF/PtJ6Dci5ygGC45lrlDlwfHASX5B8LcWL5JK7wK/avtRzQtrOV5KEIXE8DaRIyd1irmakElDOT025QNOoUiW44Gke5YimlXlWQ/jXlC1tlwk0OVkqgPP6Khg+DkNmwAvfoROdwfkFMwETxybnrgMF/nl4vffLlTs6UTOkiEKEB2erLh0wlNAhggfM1cZ/pyp/o8JFMYG0n4lHXcyXUvNC5rLrR6FlbdiBzNZSrCs2Ardk+/x+pMvc4ZxRDpBMNWbMjEiZ4dceAlML3PZC97UcI5MyqDrv9US4vMhvuCCvecyDk9RhRGY7fo2aAe0hwYKCfqZ9d0w3F3dwT2heBfE9gRRprVxY9IUsxuPUA0ottM769krE9puoXvmIXp/o3NaI67BU5n9bEiWNui5PB/D9UYS2S89cjA2mwS/sOMDNVRnT+E+AI3svhk42xDfImeHsaxnxhR4pjpkeVrO159x4D/boD0q6sVpQ7ggbNnCZrcRNe+AAuNEqeVyhotxY0kuDVuFU+G7ovuZBpKR2b8JlI58IGcjgpVVvJGfMvsPiJO117uqNLbI1BNRStmXHfs4QKiRGMZV95PNa0tdEvEzf6o3KsQ/PAWhARYQxO8UjGGprBHZvX1fUDo+UQphx0lpIU9+RoRL/tctDAQyH3MHormoNNnXV1i+mbUh/5jfM6O/qqnqNlm30l+xewrVrSN/+/CXEG4m1zD5TbhGlnvc7F+OdjEL3X0afxkk7DWtYHvnbXWGhLNj63DJt9/JSxM2bdHT3i024yKLD2OJyMwbP/QArwU63KDJ+ze8o7c1XmJ8xIRT8mU2sC+9GAlaKo6AZLv6+JdqfAiiZjqHh5eqX3CqYMJsnMzNES8LeZAt4mKs1lH27XNqlrYQLB8nseRFneiSQqaatYNT6vEU2+FdugLd1lBbHeja62NKD1gHuIQJxvN+Md2ZI 6S8HKtuP NzufqvxPF183qJWYZ+DbkFnfgh2R9oZwmOGEbcv7hUxo6gbhRFXbSUL/04/1PlULeE+vaW9dRp5Va9l9tvKcNm/EjvRQO9oDMnc/srI2nPhNAeQPRwQDMHFoe0gYCC3rxqwaVqHcvVxuxQpXIYee4OueBmNsgBdm33QH5+W8HebK3pchRESeBFs0evlNSEZIhAi0+aFk4arBCSGxrg8ap6BMYcOqf5Z+H74gXFkEPFLw8gYcapAp12OBztfjLUirOMWoTrY9AKaoc53BAcjZ5afGhXbeEtOhkXKqc9NOhNMbq6RvY1Ow66jrnLrUgGXzSkOeiYbPkva6zIPWa3obmzqfOZA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001952, 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 Wed, Jan 15, 2025 at 5:37=E2=80=AFPM Wei Yang wrote: > > On Wed, Jan 15, 2025 at 07:01:56AM -0800, Suren Baghdasaryan wrote: > >On Wed, Jan 15, 2025 at 4:05=E2=80=AFAM Wei Yang wrote: > >> > >> On Tue, Jan 14, 2025 at 07:12:20PM -0800, Suren Baghdasaryan wrote: > >> >On Tue, Jan 14, 2025 at 6:58=E2=80=AFPM Wei Yang wrote: > >> >> > >> >> On Fri, Jan 10, 2025 at 08:25:58PM -0800, Suren Baghdasaryan wrote: > >> >> >@@ -6354,7 +6422,6 @@ struct vm_area_struct *lock_vma_under_rcu(st= ruct mm_struct *mm, > >> >> > struct vm_area_struct *vma; > >> >> > > >> >> > rcu_read_lock(); > >> >> >-retry: > >> >> > vma =3D mas_walk(&mas); > >> >> > if (!vma) > >> >> > goto inval; > >> >> >@@ -6362,13 +6429,6 @@ struct vm_area_struct *lock_vma_under_rcu(s= truct mm_struct *mm, > >> >> > if (!vma_start_read(vma)) > >> >> > goto inval; > >> >> > > >> >> >- /* Check if the VMA got isolated after we found it */ > >> >> >- if (is_vma_detached(vma)) { > >> >> >- vma_end_read(vma); > >> >> >- count_vm_vma_lock_event(VMA_LOCK_MISS); > >> >> >- /* The area was replaced with another one */ > >> >> >- goto retry; > >> >> >- } > >> >> > >> >> We have a little behavior change here. > >> >> > >> >> Originally, if we found an detached vma, we may retry. But now, we = would go to > >> >> the slow path directly. > >> > > >> >Hmm. Good point. I think the easiest way to keep the same > >> >functionality is to make vma_start_read() return vm_area_struct* on > >> >success, NULL on locking failure and EAGAIN if vma was detached > >> >(vm_refcnt=3D=3D0). Then the same retry with VMA_LOCK_MISS can be don= e in > >> >the case of EAGAIN. > >> > > >> > >> Looks good to me. > >> > >> >> > >> >> Maybe we can compare the event VMA_LOCK_MISS and VMA_LOCK_ABORT > >> >> to see the percentage of this case. If it shows this is a too rare > >> >> case to impact performance, we can ignore it. > >> >> > >> >> Also the event VMA_LOCK_MISS recording is removed, but the definiti= on is > >> >> there. We may record it in the vma_start_read() when oldcnt is 0. > >> >> > >> >> BTW, the name of VMA_LOCK_SUCCESS confuse me a little. I thought it= indicates > >> >> lock_vma_under_rcu() successfully get a valid vma. But seems not. S= ounds we > >> >> don't have an overall success/failure statistic in vmstat. > >> > > >> >Are you referring to the fact that we do not increment > >> >VMA_LOCK_SUCCESS if we successfully locked a vma but have to retry th= e > >> > >> Something like this. I thought we would increase VMA_LOCK_SUCCESS on s= uccess. > >> > >> >page fault (in which we increment VMA_LOCK_RETRY instead)? > >> > > >> > >> I don't follow this. > > > >Sorry, I meant to say "in which case we increment VMA_LOCK_RETRY > >instead". IOW, when we successfully lock the vma but have to retry the > >pagefault, we increment VMA_LOCK_RETRY without incrementing > >VMA_LOCK_SUCCESS. > > > > Yes, this makes me confused about what VMA_LOCK_SUCCESS represents. I'll need to look into the history of why we account it this way but this is out of scope for this patchset. > > >> > >> >> > >> >> > /* > >> >> > * At this point, we have a stable reference to a VMA: The = VMA is > >> >> > * locked and we know it hasn't already been isolated. > >> >> > >> >> -- > >> >> Wei Yang > >> >> Help you, Help me > >> > >> -- > >> Wei Yang > >> Help you, Help me > > -- > Wei Yang > Help you, Help me