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 1F676C02180 for ; Wed, 15 Jan 2025 15:02:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF5AA280001; Wed, 15 Jan 2025 10:02:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA5506B0085; Wed, 15 Jan 2025 10:02:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96D55280001; Wed, 15 Jan 2025 10:02:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 799D66B0083 for ; Wed, 15 Jan 2025 10:02:12 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EAF181613D8 for ; Wed, 15 Jan 2025 15:02:11 +0000 (UTC) X-FDA: 83010001662.05.B476E6B Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf13.hostedemail.com (Postfix) with ESMTP id 6C18E2000E for ; Wed, 15 Jan 2025 15:02:09 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iFGmin71; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736953329; 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=WKoEDGJC0Ozzd2pOirmcKZ1n7JXZTXwqxIRqLBYepqg=; b=id2d8ilWJeFUSrEfAiwd0chJGUUrPA0xgTr5dwO3ZreVAScYX92blAtdiGJlueyUcLqveX L1jozGmpBTeQ/KTC4kukSaCvU1DqAEeZ/tsW+BSWUsUa6cpW32XqKKOVetiwphy3/y7ZeB tjHPCTGN6Sk0xlC0lVfeKNVsA5wOYI8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=iFGmin71; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.160.173 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=1736953329; a=rsa-sha256; cv=none; b=wFO7MT5RG1yYK/A/Bgt+wN3heQFn8LtG2CL7z30w5MmGQCnaqQI5+divS4fqgNRgI2WulM f1OkXabiNY7p99HXA1ZEBEg0/YN0IAGpz6GtEQ5mAMInWx1RjxDJPzH96I+EtEcZlQQfIT LGmWwgz3wAe6bSRAicxtwHyF6/2FlXU= Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-4678c9310afso516961cf.1 for ; Wed, 15 Jan 2025 07:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736953328; x=1737558128; 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=WKoEDGJC0Ozzd2pOirmcKZ1n7JXZTXwqxIRqLBYepqg=; b=iFGmin71MG3fJbrvhOEssOjZc7xblZnKxgAwAvIAFC1do/HAaL8qCNdoW5mzoCj9ym +3SDRjoMOABxTaxzQ8hzzcA2OoqdYfk0I9YMFbMzrtFu7Zo9kmkn22kPPjjuhtUHzLCu gRuZyHGmeqiKwIkYSsgS4D1heFXScwX3vuVj+J+2VKBANefRV44YUlNrCnuFINd/WCcA 08IXyNeRT5YyuGpAKfRTdcDFN+MR32cNUI1bBjG2jWrsUSfHeNWFsiihNYZ9ULpJdwAy wGSr+9dXb/gL73KVNBGJiqXzy52e7gwO0T0+q+AC2vsab+5JO7YYes6tbwb48jcNNpt1 ItZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736953328; x=1737558128; 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=WKoEDGJC0Ozzd2pOirmcKZ1n7JXZTXwqxIRqLBYepqg=; b=mluD18/egr2bZNPt1plgfUxV+5Y7C+kVGxJiHazoLQziGyGs/g6cUv8iOJukM3Uu1I RGtCwmc5QKYpFP8AugHT2Q3zop5/uRakh7/Lbe02GNluw7RAH5iqnUOSb3qlKgTCrgje j2BHieZMGBQ/0zbPinTkBwvTmNzOalgfycYkjcw1t3vpUXE2HWT+yvM82KBtK1++Cpig YNE0QbS372uwGlKSt4X9eNGQ0SOQ0JNldjERD8V1oHE7Hd4SiYOsHh61WwPAb5lA70uC UPhEUBqOH3MlSoNNdfp+T5KBW6Oby81L696CTs2zzdUZ9cKNzCj0EHfioA2a9RQ/n/1g Gcow== X-Forwarded-Encrypted: i=1; AJvYcCUeZJqrdftkS7pK7qBiOz4xR5VsK0FTpXHSJ5Wz3oB/4JZeP+CvA3uM2ya7f9hhhliaCu5nG8D5+g==@kvack.org X-Gm-Message-State: AOJu0Ywm42bBV9flZRW5y0+Qh3cdi8CeWPfDaSOTct21HnTVH8pfo6se BOplgn7y/4Gb/v+SObMRywTgdu7Et9AzCgpJRMsEqnkNCun50bwVEm0iaKeWs7pZ2GkUqif43et F+mdJJTbcYYA9n5LtAjbZh0NirYfzve3jGY5p X-Gm-Gg: ASbGncuz+tbenvUJPu/h6eLHjVfbtaG77q1KNNTmZV8jG8T/KOsdWJkC9Y+ooWckrlR /DahTPBAIHOGhElXcQIJ0CLu1CZJt5G7/BF3RzA== X-Google-Smtp-Source: AGHT+IERTcJm4rkPbTNlyT9gnqUbml15T/ofLmdF8pwA6uk+toNxp/Q8suhTk9UNqpkccFYd/xUh8FjnjyffKMIzh30= X-Received: by 2002:a05:622a:647:b0:46c:7d66:557f with SMTP id d75a77b69052e-46df56789f8mr3823891cf.8.1736953328048; Wed, 15 Jan 2025 07:02:08 -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> In-Reply-To: <20250115120532.mgvjhcrzvmmjasv7@master> From: Suren Baghdasaryan Date: Wed, 15 Jan 2025 07:01:56 -0800 X-Gm-Features: AbW1kvZZp8bgBs5oEEIeGQeVkGQIO_Eu82FA1jNG9VpM7HnO5cEmDjSZ1pwItfY 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-Rspamd-Server: rspam05 X-Stat-Signature: di1tircpg69hqwc7d7urf54tasocuz1y X-Rspamd-Queue-Id: 6C18E2000E X-Rspam-User: X-HE-Tag: 1736953329-307150 X-HE-Meta: U2FsdGVkX19TAc0anx72wWIaKS4moXVSonmblOakgnSH5R5mKq9v9Exsc4D4NLT27WC9zr9neqJMsV86cj/R268FA/ql7SPltuFkol4kbWQizlwOzCiEfjySxbtKSEjL9Zi3oO00PRr+DihDmhVA4rExPP1AffjykiziERlHUtp4rKQUDMiYL2XGsv35qOfihaMDlf+6VqrsHfdpIvSjVpTXvQtmfaM+hte/RAwMDciVpCDEXlZgCTAEcLnPNTWoHROQEcJMBnY6/S2yAEMHE/Jg7pe5YqerSepFUYznVJ4dqUgaUwkrgi4hypbOIUWn2GhFsw6hE2mqzDWI8yyD8w5Z6Tc/lhtZznfLdYBKs5Y58Sk88VuRK6PczK2Oji/IW6mPkKENPSm5S4TamUkDBsbZ8c1PhlZ7xtQjUsflmyfGLMXG7nJ2E/u3HabtGH/G4z9SCkm6TTxgh1DTWjSROyR0nj55b8Gwen0QqD0xuR/JBsA9K4E/VWBLSFi+WQnpgTzZUxYZPHRm0gf82j08nmbIjAym+Hbgyk6s/3L/L6dSN7fhNkZ3EFPA5UkdXI+/G5tA6YxAVoJccpVtRy9h7r7DsiEmByVMZaBT2wnd/9OaeBULyyQnK7KL4F3YdppzPIpfwlkx9SJkUrBT4w9zBcl4y3DzYiMglEI+c/rzjfZfiZybviwDeSWKtcO1zcO39CZFT8FOQSZiXNqBSbjXdk3aufNwBmdo4cxAEhTNvTwBEqoNMMdhVCqpfywCdYBPncAsxnJOyA17jS6e+TNjpFQ/6bgZcN8yw7eM9ZCce+HgSb08CLS6nfkMCG/MUQayGffhNbrd2iGAwFUj4DCKFoOxFzcLgiP8ca39xl2eSdt68wftZoNqTT9ytZ0gmtyyvNWTV8ZyjS93E+PgEm36cfX9Q5jP6IY/lAvPuge4387Rwq7zs/+VOpF4fRQAi0NZUHck8Id8NttT2lbSlVc 82ZHhtYw dkqVtmw9Z856GNfrmqLAn/HbQnxhmEmP3LStSMjl+Arw96uiIo0XsTXG6HYYXiMaMYRfj+9DNjVV4B1klRCbAPJEpO06D/z6Zq3tekgLxmiP8+PYIOmdustGAyxoeRyRkqiLjFuimtrXSMSBUhr5PDxrkGhiSuZWFK0pfqN1wRRdFH2CVrCsxq5+OjE/b9v3g8sQrUa1EMJTAdy7yJQ9e3ZBirJKyCXxs2Bh18tcZ37JE9sdh9qReOkpLTBfx2NMJHAaDMARQI0YCTtJau4FaSTvY2SfmUls8gadf5zbZ9/OMUToi6o6xNBJgPrHkmNL+lKHyUzymf2L4H6QJM8ngOta/Nw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 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(struc= t 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(stru= ct 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 wou= ld 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 done i= n > >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 definition = 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 in= dicates > >> lock_vma_under_rcu() successfully get a valid vma. But seems not. Soun= ds 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 the > > Something like this. I thought we would increase VMA_LOCK_SUCCESS on succ= ess. > > >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. > > >> > >> > /* > >> > * 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