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 750FBC02180 for ; Wed, 15 Jan 2025 12:05:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E8EC280003; Wed, 15 Jan 2025 07:05:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 07212280002; Wed, 15 Jan 2025 07:05:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E06A0280003; Wed, 15 Jan 2025 07:05:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C1241280002 for ; Wed, 15 Jan 2025 07:05:37 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 530821C7FE5 for ; Wed, 15 Jan 2025 12:05:37 +0000 (UTC) X-FDA: 83009556714.14.D9AF8EF Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf14.hostedemail.com (Postfix) with ESMTP id 499C8100019 for ; Wed, 15 Jan 2025 12:05:35 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PTfAkpe5; spf=pass (imf14.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.46 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=1736942735; 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=49MRHwBd9IZJd9oDgHL9CQcP08I5tNHiDFCh2rJXQFc=; b=AKlbYQpNwigRi5Q2INcnjZTScZK04K5rKq2choZbs9APwhbnOzRREky+yzohUYuyyMNopr zmKpagjq51t0luiK6f9HeYvLMb/sfANCDKY44nejneYG8l/0/JGxCHmiPYAj11FraXyTyL brACF+FBB0aYhFxsfOEEZZpLZNmAq+c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736942735; a=rsa-sha256; cv=none; b=Ra2ZkcBtWZa/SS0DHwleawhy1dXrh1lKPDg5pypWZBDFUAYLRLcoM3DlgSr0dBFW4fjJB2 q32IvpNf1br6qKqOVY2HdLuXHcwTNRXuvHHFqt+1yPO2U41f1MxmkAI29pVNv3aqWfONo7 yyC4GEpyR9MuBe8CXCUntQKMNU3HyrQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PTfAkpe5; spf=pass (imf14.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.218.46 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-aaecf50578eso1277699766b.2 for ; Wed, 15 Jan 2025 04:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736942734; x=1737547534; 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=49MRHwBd9IZJd9oDgHL9CQcP08I5tNHiDFCh2rJXQFc=; b=PTfAkpe5Q6rgGIloZkVLx2uyza/heQdDKUspQ0sJVjPkolEfiNL8l6D9vNm787Qo67 ZxFUpmiTkkLJS2kftY3YcUBGr5vgE1JWlGcL7z3IjLqVAW2AX+rCw9Zvn9X32Hh+Favc qlcvSb6W6STSgYhM4R3IomiAH0j6fBWdmNYuofhj0WxuSynS1UlR1WcimQjUXXqVdwC6 kzhpWJs0Ecrsp2NAEUOSLm6GhG07CSQluQzlcBvN81IGSwHDojSBHW+LctmPWZrpuKHY Xnk13VMdHX1bIvGb1JPsutx3M5sEy1e7NdSCu7GBrHvz88ivWEVe7kU9WtFUK5OZaBHh aknA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736942734; x=1737547534; 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=49MRHwBd9IZJd9oDgHL9CQcP08I5tNHiDFCh2rJXQFc=; b=iiQKn9sE4h2UtvZ4kq+GTq5bEN6c1gBehJ6mvQFD2Q5QyB59tItZKU3y4V9peHXli2 QTfJoXBMohybMueeMaQn+JidmlpSikO5bVcbs1eAbpY1PmMhYe/+m5Lx/3ChWSoaoVQA T4k32y+qqFSl+6uA4n6CE7YL0VZfHoKbTdFe0PtN61rW5xNphcruHgnInWIM9HF3H8kz kr6zFimKGQMZIwVEEO0X0WJSxDhxuoAKr5xIk/grnreskZlFbB9DU1Mnvpvc4Sxdfesd JNxC7Ohuurad35FWafnhvks737h7JSGq/MoB6eQqF5dLS+vhedSpd5O3EcQjRgSagJYg +jbA== X-Forwarded-Encrypted: i=1; AJvYcCUYsFA2fx8vKWm7jpEzO1HDa2GyWJUyR3tCPiPJwKKCzq+rNcJFvYhdZ66gHU+ajbsEuacGsrSd4Q==@kvack.org X-Gm-Message-State: AOJu0Ywu2uzF8SDeBtUu1J1fXJnsAEmqXtqnf2AiUHWR5VksuvZ14q8V 6WsT56ZvGWYAG4TpgEoRXIIUnWL2IVEgIFr2hNToaI+3GlOVkbVt X-Gm-Gg: ASbGncsgT/kG1ctF6ECVIGv/4xCag/q6VtIyNOSXUQyi/N7Ee9UvBQx4g/lmO19VSYw 4EMkNn4rj7PFt1PCsmMxTtCLWqPnTplZ4O4Inqg5C+TPWuCMFSipmoXZy2BKwUwyTTMcGTAScXG 1r2SqBfA8hV7bRC7R5Ob7QPwU0rdLJSv4bycCh1Bot8MLn9IrMGQNWraPpOPZcnkW+9QBlqnnEf MZCAEXmjZjbe1Jcuin8BEq3Suh2qcrNa94vPGhYaD4U9aBuXUEMKHWq X-Google-Smtp-Source: AGHT+IFJcZ5FVGw0uc+CgabUI5s3STezu9lMtBNc/pf58S/1xZ/lgQcNF8hv654Fd3SMxEAMqY9SOA== X-Received: by 2002:a17:906:2990:b0:ab2:ea29:b6 with SMTP id a640c23a62f3a-ab2ea2905d2mr1655191366b.35.1736942733599; Wed, 15 Jan 2025 04:05:33 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab2c9646bf9sm752754466b.175.2025.01.15.04.05.32 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 15 Jan 2025 04:05:32 -0800 (PST) Date: Wed, 15 Jan 2025 12:05:32 +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: <20250115120532.mgvjhcrzvmmjasv7@master> Reply-To: Wei Yang References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-12-surenb@google.com> <20250115025830.pebmoyerkruqtx5y@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: rspam02 X-Rspamd-Queue-Id: 499C8100019 X-Stat-Signature: 4io1j1gognpbqejk4rnb5yzgtzx7xm11 X-Rspam-User: X-HE-Tag: 1736942735-758654 X-HE-Meta: U2FsdGVkX1/5CUdCcdx+pHZOaZHP9P2mfpydxTQOG95OG+l107CHdBDJAgT1KEtZdtu0x3zvI0jUfBRN5t94/T0kYoop7216+J0w2zVM+qgZbtWYkslJVEAsNRxNf7goG4vthaVDyt2FFh2rSpw+3ZzlIiXS8l+IkUgQ55b6oepKzXEFwSaxGzzQGGlfbSh3cJsDMnXaUpmYI6NAC4fGAynSFQKSNUJ4i8gyLeeY/5s0L0Nqrr5i7gmws1VhUgMPp5zPOJuzp54q1nIGS31AGuNKb7PBEe0/bHLnnDR3p/TkGHAyEB7+uTOIArL57cWLJehDXO7XgfbnIqv27CknT61bz9FNtNRrSeA6X1VGhRuBxgPbMtBc28K3ULNUY/KAvawWv9aLp/xLIGjA26l9y1zLn9XtbYwjV81hdsHdSwk6BJTTnLRzPUc4fARDhmZPaATmb8VHdcvYZ9XWsQ9PfRU+tQ+HsHVzYUIjMIaS653pXUkFYTMHlR8XFPGjO1Tt1quBK97MYuVBCSpHe+HUgDwdUG9DDxrG0w7ep/XiSVaEiCmAe3yw2Tt/Q9z3PUjPnan+srpT6MyLf8ohWxyEB9A9wmYWBRTXsPD3ARpBqm4JZnOSKdfieKB7J+j5W1yyQBiao45OiRpIZ6OsSZmMlqyYol+xjDoS5fP4+bRivQ3h5QTfd8g8NZVoHBIXQ6YISUeCKiRuh6PeafVcIaEI4PoSg9OYMtd//pxaoSWXx0xjVbOOxbxThskzHNxWisIkxLCmL6BbA8QL2yJgQLL6JyWVofbKlGFoPkLHznZn1Eyb4fuZbE0AhfaHC/0QZklSIeP3kupK2U3fAPj6xdLbmmFK+rN9c0w+oRvzOe2l/PI4jdp5oC4n8PNWgvEcYVg9YN9lxGaq+JGpbQWzfb2OEnCeWv6W1f2bJyWP3MUuLpm7jYyXj7LoABLq5JwIajc75lN3hsmXeSDC0s2V2Fd mLyMKuHA DnNs0aT0iOxA1NzWn2zmuj1qR0H5/h0w8mJqlLkWcHYO1xyvhLIscypZf4tLMNxQkej/uGpsYDSEG29DTgc0SMXzKlqTjYJK7eUA2DvWI6GPn5GX4yjz4B1lxQpuz/II5AEMea5y9BvqbcJ3c8wd7ci6fiCMhJLeG1leWRexq4lNad+JPNyXcdiViME1kqcJ9qQRZmQyAcgH/oMe9oez+eNQPxxcrFrpFo93HUNZcqJQDaB4LS4NGstamiafO1ZgsoLpXRzlQyiFUEUOgEQMjJNoX6Va5MBpfXB89oDSo9WlNq0tHYom02HfgRuhLdyo3dqg1Dbi36tJdBXfH52jkpAXmutXskIOBAt5Ot7si+u0TId1NpJou7S4XovlkT5j1WlOJBm/GbpRz3zs/mIr7FMTJPvdEoo5kfNsb7h1gtGu8vJr7ZIEpROZUDrHmVE+yCVu1m3oq6siki9UfqMx7QJTBmxTVCUG12mntB9wrGhgQ8q2Q1Tmyiz+2VEPGnC1DlkelTxid9ZrceK4yfRVTmGs58opt34rACTL01dI9IivJHnWVbcy60n+YCNA+53ENaLf6wfz66GqaA6ki1zTlVwMNWh4Th1IqaGvQv3VHsyV1KoixBfve9qIAzmmynsFsCr/NsJt3ZTjEF6MZMt5ZkMKPCoOjmoxe9sYcF3A6aZ+4Vf4mh+6gnbq3qc3j092m3XmuaBjlLV8G7DR9tgO0TbTLIw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.009461, 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 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. >> >> > /* >> > * 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