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 D97BFC5B543 for ; Sat, 7 Jun 2025 04:53:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 138B16B0088; Sat, 7 Jun 2025 00:53:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EA676B0089; Sat, 7 Jun 2025 00:53:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 000F96B008A; Sat, 7 Jun 2025 00:53:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id D3F5C6B0088 for ; Sat, 7 Jun 2025 00:53:16 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 46E37C14B6 for ; Sat, 7 Jun 2025 04:53:16 +0000 (UTC) X-FDA: 83527385592.14.E158EE4 Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) by imf30.hostedemail.com (Postfix) with ESMTP id 9EF0B80007 for ; Sat, 7 Jun 2025 04:53:14 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Nj0SNANw; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.46 as permitted sender) smtp.mailfrom=21cnbao@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=1749271994; 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=MIooNSg1UO6vKmEWpNnCRekkajqCQgFQZhhnW9YK6hk=; b=4TOW4v1XcquoaBsD9H87piTUAOr09bD7hPnKgWphhNf6a3mQvbAVeLXR0AbMLgkERYY+f2 bxWdKbWWWXPAy7XRCa9/C6+JDAgJGnhhkXfntwcDJP2IzPhbKPIyvaOMaST7EjYQwPImAm YQ5N0gdKzcQDnVNDeRBp/PF/kuv3398= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Nj0SNANw; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.46 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749271994; a=rsa-sha256; cv=none; b=yyfS69vSDNUK4SLI3qR32lFJZ92H0LjF2lRzaWSUNj+3u92FUjgi1Sj8O6ihI6vjHvuxLU 9fySReZh8PQdfs0eSWFfwxXvG77uf6ty/9WV3s2+jCLalN1gz4jCBR6xByHbGkWjFV0s/T /Yzw/NC5I0VpJG8ksUee+zJ0cLhz+tk= Received: by mail-vs1-f46.google.com with SMTP id ada2fe7eead31-4e5a73028d2so818341137.0 for ; Fri, 06 Jun 2025 21:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749271994; x=1749876794; 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=MIooNSg1UO6vKmEWpNnCRekkajqCQgFQZhhnW9YK6hk=; b=Nj0SNANwY2Byl7CfzFXXYLkjddrI/mZOLudMQ58bEZ5tGHofUMaUHCXMw8YxDlFWqJ kaON83zgcC9phBFKLQ+oHMvLO1iq6jynp+Ej+rAUaH4DS7evicuUuqIeRVphOoxeJx1f 3LiYMYIHq+E+Wskr4Yf2lXqC6zeDNNh7UICo25RwTU6Yxabw+Mu2BHWdBM+gyzDzELhX 5KxT1JKpbnKsQNPmV0fsZL5uUfYtH3pDAMOIEjh2ftad0wU6LSvZ9XJSrGMFjS56VPUD QM0/KFi77dz2ThgXfQM2tAi0g3wabgHGZmSH0MGyVDrZNRga6j7Oe0Zqzv1iAXi+rGzp OTuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749271994; x=1749876794; 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=MIooNSg1UO6vKmEWpNnCRekkajqCQgFQZhhnW9YK6hk=; b=gxGCYY0iwdMooYKe2FnM+oKADI9baHcPeiyUv1wDCnPgUO/N0TWDuhzIwgN1HP/K2t NIY4jHJ0M9mi8VtYiTr1Gf6CGhY+pa8cSixWDOH4BMyLz+XsGe2TOzuAGlklzsyKwBuc 3h4pvcVQPKBnj+hsvcGH6i7jAq5yQpMXwgdKFSorT3f06RTdtd5BqNOOjXZPAi6ujSC+ trRAuP43iSjjqJKP5GSR4S5B0WlQ9+uHKbS7/hYvhq6rCcOT31YSp73NtFzMxmAK/yWL UYW7ryNtA98rIdFBU/18G4XzZFumUXKwoHpxq7fVtUroAWwALOCfKXZR47H1I9jCIWPM 51Jg== X-Forwarded-Encrypted: i=1; AJvYcCWqAQyEpzqi72USS/bI3Pg6PTPasDFtxg3O3pWbjW9wu9Jnqgs7NDRlF3lEeGxTx5reYtheUla7rg==@kvack.org X-Gm-Message-State: AOJu0YxRtbcCd+0S/Xqs0bWsMIOhbXfsqD5XpPh1wUtesOOrnws1bVoi cnWMrfMiX9hB+yBKZDvGREiOiDVBfr3MywsaLCtqefblY6txrpIlC2Yk9/M6+nqSj5SaRScXjQd SZZXVpShA/xcgCBT4lYy/7gPuBZkdx34= X-Gm-Gg: ASbGncsUsyyrTaX9JkjXvmKTuJUDf2q8/uyMob3YiUQD7SJvEptBVdzkO+k6nlsLVEW hlrm/o2GRXigIBuJgyj6ptCO7IFDj1p1Fw1nU6rCSnEyUlfCUkBO7b/3ygIKaDlV0mZwAx965DJ HmfQT1r2tJ0z/iPBL8wVV/yD/cSKLX4Yamdw== X-Google-Smtp-Source: AGHT+IGDUf1jWjcaktsy61a18I3PkSz6S+VdyYHIHk8/YlRKQVO1BjIipCaUo/Eq6T+4tnSTeBOJvDsEfT1oFYy2cMc= X-Received: by 2002:a05:6102:3fa9:b0:4de:c7fe:34b3 with SMTP id ada2fe7eead31-4e77264eb77mr6327504137.0.1749271993663; Fri, 06 Jun 2025 21:53:13 -0700 (PDT) MIME-Version: 1.0 References: <20250607004623.8896-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Sat, 7 Jun 2025 16:53:02 +1200 X-Gm-Features: AX0GCFs3CZonaFcFqVyazYoNoWE6X0NXyHkVo-n7Fw6MSugWNyJiwNgljphKH_A Message-ID: Subject: Re: [PATCH v3] mm: use per_vma lock for MADV_DONTNEED To: Matthew Wilcox Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , "Liam R. Howlett" , Lorenzo Stoakes , David Hildenbrand , Vlastimil Babka , Jann Horn , Suren Baghdasaryan , Lokesh Gidra , Tangquan Zheng , Qi Zheng Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9EF0B80007 X-Stat-Signature: cb5n953d1ikekigdfzijb9x3wirw49ah X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1749271994-823581 X-HE-Meta: U2FsdGVkX18fEhgIWMAp0QkrHKepN9G/rjIiJ9CEupKdHgFu2dQYh61Uj7jzC962ed9iWAm9tdVjtaS/NrUhYBKDbr7gNlL224jtQCtq5wBlUc8tWS8sVfu/zqbNJCBLLPb/LoQDrdFo/Yl9/7BYzdedFRbkA4uqEUMfl4BC5CP3BvJ8XF6DlzMFNSRmrv/c8Mzp6p1t858Rh67EGgOtIA5QxZ9EEXTuUYf5We7k5eWoMhZZudms+7wtbK4h2rbODv9PDZCm1xHhPvu1FkvrJ2BT2NDKwcSTIBnOERFpD9d5ToVzbnUsorBg9Acqosl8sBa4HuKqg688NBaLnXT3HTeM+n39UC7y4Mwd008OOeo+8FI+jIlFTu3mrao6kLE3uxNPK6wiHQF7BslsIwugayv8j5o13tSElp6CBrtEAQq8yIRW9WORPtX1sPntF2qn7YFUOrV12vytdfIdugZonqqGbRnCWa81Q5A51eWF4gZSx+n74EaIGZ2urLHPmm8wDw1FR+QUHTg+u3B3SIUmm6xKSpQOxPhOoNVH5rO+5jchOoFxOmIHfR1nqQeo8W6vFQNWnLi/x0Q15qcy6iTCu4m3Ug92/LuDsDsUy15lSIhcXejPZCl00SNhwumcKRvbD9YJJk3Ta4g60jakDCNgKS7lvtj3SHI28MWgYP5B8hFldp11ounVSWPa4CSvbI3gkMhc4+vg6DLGyD2/eUEy+l/q1yeFzVX91+0Fj93+dSlC/m00TITCpJ7woBMt2FvcrIoEUnOgzs++pj2zcgUffia98CDCllYQ0NOssdyOGSNL1Cx4MWkKWl1qlVj9fFssVQotnKqtJvGF+YdGH6cvq//8aXYnCJF60lxB+3fv1tc8R4/OkYEiGmSvnCUs8OeKf6M9F2yNOmD5U3XHY2K5ZaWH9nEQzzf1RgJTjqwSqVye8UN2sTAqrrdfcA+Mtz4TPAY19PGyP/Z+DB2oXu9 5SdqdmMh btL+M6Z8btOYfc4Mjfa/RiJj5xA== 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: List-Subscribe: List-Unsubscribe: On Sat, Jun 7, 2025 at 4:05=E2=80=AFPM Matthew Wilcox = wrote: > > On Sat, Jun 07, 2025 at 12:46:23PM +1200, Barry Song wrote: > > To simplify handling, the implementation falls back to the standard > > mmap_lock if userfaultfd is enabled on the VMA, avoiding the complexity= of > > userfaultfd_remove(). > > This feels too complex to me. Why do we defer grabbing the vma lock > so late, instead of grabbing it at the start like the fault handler does? Hi Matthew, It looks like you missed the spot where your comment should have gone: https://lore.kernel.org/all/0b96ce61-a52c-4036-b5b6-5c50783db51f@lucifer.lo= cal/ So I believe Lorenzo is the best person to respond to your concern. In both v1 and v2 [1][2], we did try to fall back as early as possible: [1] https://lore.kernel.org/linux-mm/20250527044145.13153-1-21cnbao@gmail.c= om/ [2] https://lore.kernel.org/all/20250530104439.64841-1-21cnbao@gmail.com/ But that approach had its own problems: * It's not extensible to other madvise operations. * It's not easy to adapt to vector_madvise. I also initially found the new approach too complex and tried a few alternatives, but each had its own problems. In the end, Lorenzo's solution still seems to be the cleanest among them. I even forgot to move the code below back to visit() from madvise_vma_behavior(). I had changed it while exploring an alternative and should have reverted it. + if (madv_behavior && madv_behavior->lock_mode =3D=3D MADVISE_VMA_READ_LOCK) { + vma =3D try_vma_read_lock(mm, madv_behavior, start, end); + if (vma) { + error =3D madvise_vma_behavior(vma, &prev, start, e= nd, + madv_behavior); /* better to be visit() */ + vma_end_read(vma); + return error; + } + } Thanks Barry