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 1A232C7115C for ; Wed, 25 Jun 2025 10:57:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B27EB6B00A9; Wed, 25 Jun 2025 06:57:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD8156B00B0; Wed, 25 Jun 2025 06:57:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C8116B00B4; Wed, 25 Jun 2025 06:57:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8B4786B00A9 for ; Wed, 25 Jun 2025 06:57:42 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0F3B5A5427 for ; Wed, 25 Jun 2025 10:57:42 +0000 (UTC) X-FDA: 83593622364.22.B6ED320 Received: from mail-ua1-f52.google.com (mail-ua1-f52.google.com [209.85.222.52]) by imf13.hostedemail.com (Postfix) with ESMTP id 3BAE52000E for ; Wed, 25 Jun 2025 10:57:40 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=d222FW3m; spf=pass (imf13.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.52 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=1750849060; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Fj0STZsYtbu1kQ3gPY9FIOxyqjDAl+wTNEIVZVCZURk=; b=3O0talJ9AS/84Hi5xnHORKYN30utqiLFwYwzReT3YJdGblgNmbMP5NWV0mO4jWYCa6PwIJ b+JpVEE6XQI1/auaahxDCZ6MyOynFQSaljJVxcP0agnpMkyTbJ9E6beboP01EEIoCCRf3z yOutIYis7872T7Z45cKLDQXUJcdSdno= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750849060; a=rsa-sha256; cv=none; b=cDMOtKU4oJb7mlgVq4+zEm53BSu4WB31mcmkkDJXh3GVoLJH9kVYk1VUpMz6L2o8yifsgp AMbCrar3MfctT8fDpf5BIj3Mx1FmflfUlWHcZfQSh+H70s80JHOHHxLlTGWR28rO1JmyOU kD/+aDLArj9/ew2inRADbkKJwSKMGmI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=d222FW3m; spf=pass (imf13.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.52 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ua1-f52.google.com with SMTP id a1e0cc1a2514c-87f1bd2229aso1397328241.0 for ; Wed, 25 Jun 2025 03:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750849059; x=1751453859; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Fj0STZsYtbu1kQ3gPY9FIOxyqjDAl+wTNEIVZVCZURk=; b=d222FW3mpO6GTbXXwdXUizqWvkB0TOapCOwG9voCMGZyIf0iAHUZZQsso2WLofV5KB YM4WNIZm3BRRXTMUD2pri7YDW7X0/6zmrdBPn99nXHxUY0NIHZK6EKNfSa4G+sdE3GPh SRAeQNodiaLQRBv/RSSH7weIgFkFm8NYAEcjbgRlaEz30gifsIoskpgr6sM6AQWolxQD QMYx5+l5+DszjBQR8Nls6bBd893sQGZ2BTcNoUknBils6Gnp3OjxxPvUcms1CY0gHYW5 j7VK8ROkl/wwxsCCgEU3yshz28KO30KR71iYbUBHR4IzUWWoycWDNM0iHU6jAj7baUgj NCnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750849059; x=1751453859; h=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=Fj0STZsYtbu1kQ3gPY9FIOxyqjDAl+wTNEIVZVCZURk=; b=qprk32pGY5gt3biLgL13ugzG9zBR5NUdEAgUExr9ikbxjtVEp8tk5ONazcRh5vSKPc AXA0WGZgu7RNSN4HShhswt6vnPualGUPJxgRlTIbfWDSFKw1rw2evlQslbgEj8UKKJMY IoiE5QeoGN2pAdkxT06a1RfQFIeev3AmR2bjHyn1Wr317z0yRuA7VmJ498lps0muxUD3 eXyu6+SkhgvR9g0kAmNz4+aFIIL1u9UU+Iev1c3lVCYrufPjan6HWU/ia2LJspGKKiwc 0PVvW73zLnqZ+6HqcRnheDEs5BFfmbspX+yKd95mXlin996HE3tjnBvQRFRsApDXUY+Z uZ3g== X-Forwarded-Encrypted: i=1; AJvYcCVxhFkB3aPiPMYh0ss+ksCKHdZvqQ26458ur3OR7Ppl33Po0dn4bxVGibu9hyobdwYZOj3BDbFlaA==@kvack.org X-Gm-Message-State: AOJu0YxRyKJI3pu/xnqac/h8dlLr2xloCoI/29it1CbYwjRDHsXct18t O++j+FPsfmdJeqSAXH/P7DakTzbiX+Ih+wyjywkEu6Dt4UsI6tPnVNu9OQ39OgqrvGpdV6NTy/D ytpkP2YZjbcvnczwbuRc11xAlg4gN6NKMRkbB X-Gm-Gg: ASbGncvLOMacIR7eEQGQQ3lrZqHNMnt1FcuP0MygztOqqquRH9L8QgACFB+Sb5gHl8A cILktjLbgVqF2Czxk1/V+eq04Hy9IHXFKEDrNGNDSHT8DHdqvSMDCThdYePEdWxz4uIMqC0GyFf oc0fdj1CB32eBJStCpkQdVZ3KHD1SG1F9YOEsrWS0ZM6Q= X-Google-Smtp-Source: AGHT+IHxYZQQdKiWNAVrM7n23h4q54LeHy4Ec4zMJQOJpG9fbtf7HmW4k7rR6lcFnPnH4b5aUcO70ihcOUZ137GEwrE= X-Received: by 2002:a05:6102:919:b0:4e9:add0:2816 with SMTP id ada2fe7eead31-4ecc6a6eea2mr1102553137.5.1750849059136; Wed, 25 Jun 2025 03:57:39 -0700 (PDT) MIME-Version: 1.0 References: <2c19a6cf-0b42-477b-a672-ed8c1edd4267@redhat.com> <20250624162503.78957-1-ioworker0@gmail.com> <27d174e0-c209-4851-825a-0baeb56df86f@redhat.com> <938c4726-b93e-46df-bceb-65c7574714a6@linux.dev> In-Reply-To: <938c4726-b93e-46df-bceb-65c7574714a6@linux.dev> From: Barry Song <21cnbao@gmail.com> Date: Wed, 25 Jun 2025 22:57:27 +1200 X-Gm-Features: Ac12FXzTXMGVnpcik-Ihc93WyWfYdygYrAzrCh0xDLBYAYx4TBPj8MQP9kn6COg Message-ID: Subject: Re: [PATCH v4 3/4] mm: Support batched unmap for lazyfree large folios during reclamation To: Lance Yang Cc: David Hildenbrand , akpm@linux-foundation.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, kasong@tencent.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, lorenzo.stoakes@oracle.com, ryan.roberts@arm.com, v-songbaohua@oppo.com, x86@kernel.org, ying.huang@intel.com, zhengtangquan@oppo.com, Lance Yang Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 3BAE52000E X-Stat-Signature: 65d1i6t56xk35fhzmr5y4g95c43qtabx X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1750849060-488353 X-HE-Meta: U2FsdGVkX19vdBO6krc/V+2levAhRrutpNV2GMxLX7cZeCtPkVsRosufHmzGW8X0zvhPtQZz07dm0/zHz/DTSVL9DvCClI/efHJsE3pag3i4QDkSKVlkGVlNdbaDI6Hr69JPWc122EkAawX/FUbPoC5NZCzSqYBZeoFq4aJnkDqrz6X4qOPbwrFAvyOrWb0X7e8YJiRv9ck3zTJuz0pm6e1KjOAz8duFNFqftmATOWFPa1I6/MvqHNkOgFd00U0TRAKz1we4uawH7lrX7yphgkPvWVIRq611WbOE44FMGiA1jRhzpNkZPF+3f2QIO/EmJ2/fUQc26KIvB21KfuD5z8vkpwRd7YSrXbDFLCut6NDxaDyukMPy78eoBtYO76+YuLhv4EDLk/SZUp2IEhIxopXu4q+J8wzTiuLVrwqHL92tbFTUhfi8kphJzHmrT2VSMe6bb66zHjVmZWu0YknZeCLVh8EMZ9lgjMgTGS9Xv8KDmfQ+fa+iEnmnEk3/Q+moeYKwMo/FGoIXWPueLBFaecRSj/jxqlg9G/MHQurT4jHTOcyqgFpujquuinVLj9fF9TBg5vip1HGFrpiARt+5pfPG7UIGn/eINWjBiSbvtVzJGMQRtUvmRG6D99lJKbQssUm6s1El9dWs6mGd8sPuAW80ju81ZPT7xn3fHy/jlaAqmiQD5X8Hgcd+PzuN5v/rP+xxRmKnH+ZZ7c967fKCBKrJw5NVLyL4g8GCh7uGwTKFMUeQ29QcalUVUG5M4baHWwuEHqO0rKSDisW3tosrhAnG6bc7zWOemUxpO3gylpEhRyFFBeiCceCzwOyTebdbutmsPPqnDSJoyPQ3K9dOgWsSbn/UqSu8yiklDM3ujEhfb2aqjJuxf+GPxlY67iWSnkPprX58YCo7Radh2rha1Nad9TPkEJ51zkILiROEY34AahqepI2hhpYd4r2DW1vqME2KbhyQ7aNOidZ84Qv DVZwwZ6j LHY3mG/Xqxo/gm5ztpSDWmPMF8QwPLHbX17HrsjhPZsIFU91vcVrvVeREXfPf2Tb3Alm3lxDMKjwDPvnAUZesWRI6gOHWk/Ck1kANxXw6exgas8kvz8SR2YtcpuVANt6S35+0dh8PpKaNJwnH5D7bM3yKXKmglG4QGzz+2s6ISyfsCscjMqdB+vRCyc2FE/VfxbYilh650bIYnWEDA5JZqL7qKGaV7Wq/7hU6AGoXU5MSInwa7+r1UjcWgcQEYuVr/6CSfPCU9TpcG2BpuLXT9LkfabgnIVwp9kJUmI93suWMBwe71EqVgO0wRemr7C5WmFrXQKTeJj4HeDUjXAOUxA8e7Fv03i7L8CtGCV1venGhtks= 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: > > > > Note that I don't quite understand why we have to batch the whole thing > > or fallback to > > individual pages. Why can't we perform other batches that span only some > > PTEs? What's special > > about 1 PTE vs. 2 PTEs vs. all PTEs? > > That's a good point about the "all-or-nothing" batching logic ;) > > It seems the "all-or-nothing" approach is specific to the lazyfree use > case, which needs to unmap the entire folio for reclamation. If that's > not possible, it falls back to the single-page slow path. Other cases advance the PTE themselves, while try_to_unmap_one() relies on page_vma_mapped_walk() to advance the PTE. Unless we want to manually modify pvmw.pte and pvmw.address outside of page_vma_mapped_walk(), which to me seems like a violation of layers. :-) Thanks Barry