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 D4D74C02180 for ; Thu, 16 Jan 2025 01:37:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 652CD6B007B; Wed, 15 Jan 2025 20:37:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DBD06B0082; Wed, 15 Jan 2025 20:37:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45555280002; Wed, 15 Jan 2025 20:37:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 240B76B007B for ; Wed, 15 Jan 2025 20:37:55 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C83A9C055D for ; Thu, 16 Jan 2025 01:37:54 +0000 (UTC) X-FDA: 83011603668.10.B5512A9 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by imf22.hostedemail.com (Postfix) with ESMTP id B8577C000F for ; Thu, 16 Jan 2025 01:37:52 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VhUyqPfU; spf=pass (imf22.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736991472; h=from:from:sender:reply-to: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=+gLW5ffMlLJHnHlMar0htIKFbkF7g4jGvufIPYktGs4=; b=4e4ZYo+zyHaDWI7pK2RzMcVRq0ECwgcDks3hwNxAvVNrWO2j0tDkaxfxFfpgWGs3Dd5zAX cOSaHW3369QIMepL9P4ZtXdI8QKkuvAyrGjtx00rbV7yf31xbvM9TNvTDLUqRkWoXtvexQ RT2q2n6nWXM0rjx1UPXolAWSjgbc6y8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VhUyqPfU; spf=pass (imf22.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.50 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736991472; a=rsa-sha256; cv=none; b=BIKRcyx0XWiOMegAlhzwMYY5XYasx0fWqcLF2DFxKvr7OhsyMED7kBI/jHEKliAuQ67x3N K/QZg3Uj9A6LdiCYNrUQQHsPqq6MFsjqxiylfzNvx6naQ8ydytvHREa3Ujy0h0GKfGMusK ODuk20UFeCBDkxJzd5LOozh/Fry/W0k= Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-5d9f0a6adb4so792256a12.1 for ; Wed, 15 Jan 2025 17:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736991471; x=1737596271; darn=kvack.org; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+gLW5ffMlLJHnHlMar0htIKFbkF7g4jGvufIPYktGs4=; b=VhUyqPfU9rCjwwtLWBPhCXpTt9RHoJr0BJtchD3rYnD6pBpcHJvI2OkFn6fZQumV0k a8mbDoCW4+Ul+/i4BnuPQF6QHrY7aeurzniewkyqBwWqRcCnaN/tnk84nSJkN9BjZkNN Q68/Rg5D7ZngIKHEEF2qlRqf5KbV6aFe+CfbcT8HAsQyOiIqlNofa8ta85XUes+TBDAF pYoj0Woh/rrZxZ0MQqABIlIk3cniZKvnFS93/xzXBVIx6hrl6fUEkPo7kgqjx/GSKWVB q6tVidCMUdfWxfcO04RcXjYvHaYodcBRxkQgWGcKW1S4cU0Sy0Qrn6zMP0cMvoEQ9hSk FJIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736991471; x=1737596271; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+gLW5ffMlLJHnHlMar0htIKFbkF7g4jGvufIPYktGs4=; b=RoczH+8yh+9oS9QWzChTQFyFDMmudNTqflt4eqSxO9LzzrkYl5BaOc1tPxj68uS0ZW iRLh9VUsVCFfepEClbt9asAEGJKeOX/G1fX0jR9kKEKVLkSl7MhFhgpRvWuxGEHSOYTf HKYGTIpsBftLWCGR+22oJ+ZI3xSlg4jpsNNanJ2jK8/nHt1+A/CEtAn7a+QgJaBrqKPK 2RDli1FB6Sssz+Gh7gsfdTpSD3+shbGaVdHdtD0FbbiGgZmW1ffIZ+9KHhod15W2yQs6 AG4DtXUqP07MDNM4fXqOB15XEjWjQlQcO9mIiCo1IOK2GnXrK8xvAL4PGWlXPHPegv7w d0gw== X-Forwarded-Encrypted: i=1; AJvYcCU7BCjrpOVyK9JaHDGSuty07wycDCd/iFdkpwYh7h8w6guhYxLny+OV1lzXXsFst6DLTllYnLRc2w==@kvack.org X-Gm-Message-State: AOJu0YxdV+0gajKicCzy087ZB/EBrkKdD6Jxp2MFF0j1sAxOGhbLbGwy +wHvt16v3jALMRGtaWW/0YXkqAiU/NpAroWJ/eRG0RV/N14XGnZy X-Gm-Gg: ASbGnctEIqmjEmYqfkwHqdrVW3Hhyt75zv1PwL7JK3YfDmCOekrmT9wwTJ1u6NYruGd 6KRpYUw4+TzI4BBUaJ/blg5/Xk0+r1+jsNDRH2OukDRg/vt+p+8E3yrBrrnCT1VbwGGL3ZIWjBT U14dWGYX/sYGRTiq+oYj+ZH1I6l2NJBuxVXJlasoq7F/+P6ZnRFjG27rB/T1yO904rB8T1MGhYn 95BXeiYl39AA10wB19MP7T5uu1bt1rYXfj3UH/Z2sJ86VTxydwmqEBm X-Google-Smtp-Source: AGHT+IHHwk40aGVXkXnzgu8FYr8Kn0JAnVq8YIrAZEO4dENABUgiNmiNYFSaIZHau0A+O70KQ0UxMA== X-Received: by 2002:a17:907:2cc4:b0:aae:ec01:2de4 with SMTP id a640c23a62f3a-ab2ab5f52efmr2780226666b.30.1736991471104; Wed, 15 Jan 2025 17:37:51 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab2c905ec4dsm828953866b.35.2025.01.15.17.37.48 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 15 Jan 2025 17:37:49 -0800 (PST) Date: Thu, 16 Jan 2025 01:37:47 +0000 From: Wei Yang To: Suren Baghdasaryan Cc: Wei Yang , 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 Subject: Re: [PATCH v9 11/17] mm: replace vm_lock and detached flag with a reference count Message-ID: <20250116013747.akajp2kdwhmbgq5r@master> Reply-To: Wei Yang References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-12-surenb@google.com> <20250115025830.pebmoyerkruqtx5y@master> <20250115120532.mgvjhcrzvmmjasv7@master> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B8577C000F X-Stat-Signature: 9uw8twsry6ehtt1wo64az16w3gm6x5jj X-Rspam-User: X-HE-Tag: 1736991472-807494 X-HE-Meta: U2FsdGVkX19R9X9JWRcABAI2pPMMMNLaEN20TVcPz9HM3eMDQkFgG1lTuTuVWiN/c075qSsXBSO5rrD3fZNdZKmxdJhWE659qvqibCt1buqJQes7QbyoOd2/gaPO5JYRpQ2+00cNouA+xWy8M8MFBEryj94MS4kmsyrgfbdoVkHVykCBKuxMHVLR3VSs3/hZOOluYZqlEtyfVUjSUIaVgnr5V0uwWjF2lRSlY9U1tdV0h2YIYKgkZJsitqf1zqxwLKBtd0x3x0NqdAWqzCRgQpVjTPI3b6OSHMsD2aU1dTCi5wB0TB6JRwWPkSj2xm+Wtm6TjoYFv5cj3Ij/yLwb1yLUSodcjRBjEoKlS+ezQ9i5aJ9sJldr4DEso7Gj/B4A7ovWc7jQf9Mtr4rmXNMKGckjpSHH93WylCdL2Y/NOUe5hmwPmP6+fWQr6BzQmY+I98YSRtqyT7uLJHRvLRwU/yA1lee0swwnkhagdKQN1nqVDbOjaXBMlZFxGnKszrTiopR4sDF61Sugt+NxkAxcdXVPkdJo2u9Ka8OyfGFaEevVgQQvlXHeZLtP2nXtSEmVU75sCC68iPIGxPA+/b9iWfQlq/Tj9oPkBv7N2IDNgEuARQkZm6K+cXNtt4F+ZmyhnkaMLaPGpfQNXrk3v+J0UW0qr8tckSXMpt1x4QCwvPx133NGE42YY7ZjNqx4O9aFcm6yGz28nmTfN+PUvOGqXthnotW1EF8LEMWyfq/lQF9N1YqMGke+3rVMGvT20gPSon8WVB39P4XYjIsXPEQ1MB3IFgp2ZD7w1DPrt7dsUUzyrEgdLmCWami8ScWIrplBPXbj0YGjRcojtMiAONayqFKzZ3NC4upsqWKvpNBv0qnlOVgLi4M5uA5HjWa+tBA8/YJYMh+0aewzJ26zIne5Jz9Y9gFjvarwEHxuVNLglO3s/mqmH/jLAQd3Bh0wb+TC8AEdiVCPiHCrEI4jktw kJEk0SuV LWvUFRfIKrXgqH4txF3kKoqtCiF5KyUJy3k3KS24EVbCvzSwWgn48NsDtReZLagcVGVi+MA36vZUCIMIv5GRItMs6mBsGNd13yidHj46qW7RfUpVZjCmTr2HjB1SIg10P/g/FowBhJYSXkhs+XN7hKyW56zv/BKSJsM/6jlLeHZ5RFVK55xMRVUn0xQ++DAtKXy1oM4PS3x5Xl/eRHQNIiw4LIWEEtMVtzJveBJgtUMKnfQdBW6xIYRSyohU3VK8tEGW+FWLYrdkfsTMe6zDIBR4MXYcUs4wteLEb+rahZrXXlLrYD2EYJ/YHn8Up6+9vLZplsOjR4Vj7K4b9YDn0QntHyVqCeZV7riYeGDiB2Fipn29cXgZ2ZiJ3Qt2yxrnGepICfFj5O+X0K9GohH1W1WlTMUI75e/wRVsEze0qM2SHarOBGfy/97uH8t0pjghMYAGFq1D3ZgZzPHXB7f1c4l7QwkhZpZrJRuZXn/BGYfZy/8cwmoRdx91TYRiRTXedsGKSuxDwP6y5QNodqw+r2uyqDqOJojPKGZPwsjaUe9G9zo4gmRv7uexbhDafpXccPx4r4SYyi3RNX86+jLAYQUe/AAjtyIO6rgwYO9KNbm4SRhxD6Fjz71h0vwx6xW8iftRLPm2cOwPlJSSX7vx/KS5nhHpBE3hADykHrbDloXYxWMCIIci9pRcFtZMvaJq42XTEa+sEWTlQ7QVSY/7CG6HWhh7+9k64KoDecVTscUaIvNvfhL5v4HpsMESqw+84aB+tIHkrKPYWXW4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000032, 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 07:01:56AM -0800, Suren Baghdasaryan wrote: >On Wed, Jan 15, 2025 at 4:05 AM Wei Yang wrote: >> >> On Tue, Jan 14, 2025 at 07:12:20PM -0800, Suren Baghdasaryan wrote: >> >On Tue, Jan 14, 2025 at 6:58 PM 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(struct mm_struct *mm, >> >> > struct vm_area_struct *vma; >> >> > >> >> > rcu_read_lock(); >> >> >-retry: >> >> > vma = mas_walk(&mas); >> >> > if (!vma) >> >> > goto inval; >> >> >@@ -6362,13 +6429,6 @@ struct vm_area_struct *lock_vma_under_rcu(struct 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==0). Then the same retry with VMA_LOCK_MISS can be done 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 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 indicates >> >> lock_vma_under_rcu() successfully get a valid vma. But seems not. Sounds 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 success. >> >> >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. >> >> >> >> >> > /* >> >> > * 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