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 B1FCFC36010 for ; Fri, 4 Apr 2025 13:37:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E093D280003; Fri, 4 Apr 2025 09:37:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB682280001; Fri, 4 Apr 2025 09:37:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C7EF3280003; Fri, 4 Apr 2025 09:37:27 -0400 (EDT) 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 ABA88280001 for ; Fri, 4 Apr 2025 09:37:27 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id AB28D50449 for ; Fri, 4 Apr 2025 13:37:27 +0000 (UTC) X-FDA: 83296463334.24.B9BF62F Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf24.hostedemail.com (Postfix) with ESMTP id CCCC2180005 for ; Fri, 4 Apr 2025 13:37:25 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=jn4wSOcM; spf=pass (imf24.hostedemail.com: domain of vny@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=vny@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=1743773845; 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=GxbZagmBwC/wl/GfsJMJrzVX6h8neaRQ1Nn+nU+FoIg=; b=6XwsWTOh2LBv9okcoEg+SXbYG44u9MZ42JwMQ5FFkvcOp76C0jcfd//horPi5VUvEEN3P3 D1oYZxAExgs1AceY3MCjv3e8DbzhEtM1a+np2rQ75rm5/M+at0SAC9eR4XiG3C6lbegbi4 HX7AzuHsciZVOYxfpSyZvoluRiIb0TM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=jn4wSOcM; spf=pass (imf24.hostedemail.com: domain of vny@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=vny@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743773845; a=rsa-sha256; cv=none; b=uUX6L14bIvTT0S8W/zdTRjZJmzxDw1FVeXj2LD/6e7IZmikuJz/h8GbWHNpcQ+aZ3tesw3 oedXse9Lo7bIhvf8ixIc8dYGBbEhCjAmteBP8PUJ1O2NXh6QlURQvMEcZ970w7GcYL5kZ6 MbKabrkA8atjTx96Yn5gyO2Gnx1TnyE= Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-e6405b5cd9bso1804954276.1 for ; Fri, 04 Apr 2025 06:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1743773845; x=1744378645; 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=GxbZagmBwC/wl/GfsJMJrzVX6h8neaRQ1Nn+nU+FoIg=; b=jn4wSOcMP0aIvqv5Tmg92Z9OhD71I6g4ZbyrqjbNWDnaJfTozljsRQ8ft9YGRuRzI/ sstUwAAAAKpNkjgqa5zUOOsR9fJFyBrpXhhZO/7Xe0xfb9HQ3NIjYIrGKDRPL85k9CyY tLCK/nJsYFUUeJdwNeGmSxUKIdsL+qjRW5XphaKXp9TidqS6Q4rDBnV6nWO+5/I3/zzf hfz9Vrea3/e6iiAsiFzXP51fxw+OP4DXQbRqjffsZA1A4DIUNttmUxWtLFwTMFcn17yu 6owOUjoExsSfF94u+6Fd7aMk9OVPCsLmmM2+UfHdyOQZGF95zhcXbGLHl9jY01u0qSSr ztLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743773845; x=1744378645; 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=GxbZagmBwC/wl/GfsJMJrzVX6h8neaRQ1Nn+nU+FoIg=; b=gdcM8zmqAvMOe7E8AhSIip8snU/5apMfcdDuvTuPwP5KZmsWbzNFXEqfIYMP7eIliR 0HJ0LT4t3giKP+Z7FiyXdjzq1SJrqY8t4guEkcJbbpe5qDVKHc/pR/1xyxj8rucRN4Cv N4Xb+FSkYsYCuSbDL9oW5p6x9NLrXw8zd0xc+cNzRXhIEt1O57VPBK+xkmU5EzAKlDoA BuJr3CeUrRdtZqbID5VTmwzcKrjAL/p8Gg9Rz5ejqxUzFQYPTkbGPmsskK6Vz7tuRjJl BlMzI43j4CDsFq+9tUIn4mrdBkFetYgl6Du0R4YQ1L5WDhO6DMpWWn7ROHFWUY+lB/AV ac1g== X-Forwarded-Encrypted: i=1; AJvYcCVPCFH3Qk67bM3zXT+qyQP/l6Xg4PoMUmlR6Xv1z7tATyDg/4AYG6zcfjWb/io8x+soLtomH9OPRA==@kvack.org X-Gm-Message-State: AOJu0YwlWP+pafbnqBjju/KU2afbG4xRqdNf3mw2Ci/rURZpti8dBBIt CxW6K7UCVS13nTFsnlbUKT2j2zlCkYfjlFvkFajPlIwSKyJ+hIsDy4PGZ52mYX0acdBecNLCNqD jmvx8d4YKrIwexLLYBHT6ibC86JxgK5BulzBs X-Gm-Gg: ASbGncuQGJCVlIsE0MrlKtIp+s5wL4tj0Y9sZpu/WTBGobsQZieUPWHPHsK/twaykCy zOQnnIdt6St6cGVyqs5yQVds9Yo9lBK3sj2lw9V5E+XynT9WfU4ddFnS5aAQyCpjd08aFSe2IKr egTxcQkYTJH65IONeMBzL4iBg= X-Google-Smtp-Source: AGHT+IE49jluc25XCC6KwW5XyS869R0j51R9CEaS+F33GdMhH1lt50gslQleZPCt8DrKu2m5zayZ2fbtZ4GKxdJ0g1A= X-Received: by 2002:a25:d648:0:b0:e64:3f66:90b8 with SMTP id 3f1490d57ef6-e6e1ce8a9a0mr4831050276.3.1743773844689; Fri, 04 Apr 2025 06:37:24 -0700 (PDT) MIME-Version: 1.0 References: <20250328142055.313916d1@fangorn> <20250403150055.94a38bc7e6e3f618fbc23ddd@linux-foundation.org> In-Reply-To: <20250403150055.94a38bc7e6e3f618fbc23ddd@linux-foundation.org> From: Vinay Banakar Date: Fri, 4 Apr 2025 08:37:13 -0500 X-Gm-Features: ATxdqUFlRYmMZcSEAkjFOm9V1cNcKDKC2DRLB8Q1RsZAL3bqsppVl5Z_t8nQsAw Message-ID: Subject: Re: [PATCH v2] mm/vmscan: batch TLB flush during memory reclaim To: Andrew Morton Cc: Rik van Riel , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, liuye , Hugh Dickins , Mel Gorman , Yu Zhao , Shakeel Butt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: CCCC2180005 X-Stat-Signature: u347aywf8udrd7xtpqggxrakihagmikh X-HE-Tag: 1743773845-507279 X-HE-Meta: U2FsdGVkX1+1nD2MBBzlwKXTVto7uDh/pWN4pV9Ih+cQ0KVONwoYJvTTeeIvjWBfvBTZi88u6eh7mt1yB2scIhD3QE0Hbtk3i5rovLZhrQ5Pz5OP3N1fMVh9OpM+tXcNKHLauUg7WSYYaM3lrbT3QEpLpa3j7x5tLXyvT3Su63DHYJtl3O4gUQ5d/gABHuNppwQI2Tq+HpyWUCTB4vaX6LqhIiRfLjRRoGw39Gl04TOqUXcQVCjCWVRvyelpI0HBap2291xj89nQmbTSu1g5GAR0V4W4SjTzN/j5J6ntAyZTYcRZLDFiR/WIz+5efmTsNN06dFVEKKQq/Deb0rpOLsF9f4V3L8W/B63czAfpgXPPAXCkqPXogLEyfPCq84kOsOLideta2EiFLtCdXjedB/Z8cU+4TfSaVuqCGSpiHikRQfU9R0cd+d1EX2xrKPvw3fmTzC5y1sy8h/aaM9a5Jg6ZHPEMNsk7OBYVkYtoGhVkxl+s0dU8ZyJm4S9Fw3zUjnrqS5Tv0ZDFy29usFYRQ8FUGJuktTae8cwUaB1AS9ZTgZJUMJGT7ZBMacnk1HUCfiwQhoBDFFmiiUNw+NhYYaCnFWa3gOIDUmBwCA89ny9Akf3o8J5C/7t3JSIYcH3L6bujzR149zMDeuu9jaB8SghxOBc6NDioG6QW6af2t/mEmUcqac5g+iA4tZj8NCpLm5/5r9Ho9hYg/6Cby7z79RWxPHRS/esMLPtglIGeIO4rj+9oyXjbwH7C9MDCjY0AthUAH6WXKcS8Y42y6+tQ+1OFzW8b2U9JD+o63H0IZk1GXqtw9755696/CBCe3BzoezMRdS1augD23RNVEiMu/JGhujM8xAEWbsDc3VJLZM/Pu0hQbrsXwqlJbiY64zSijJMKRIiRlMO9g3gFFRzs/7oltY1yQobYW+HQWowdCaAJLgrvUKmUyjHKx0o/DXocx7k+69A8m2k4eoPM9pj uAaTIXfO rFm5694S6osN5Vt6v2ReVPd5GeuxKhO+oOUWqDEKCM3MFiDjxcQ9JGT1Zh3inn0nOjZAAFUHFrtfrstgfKl/ca1zwvPsC0bcMCm1Ze5vr2D6tsRnobDaKh7ax1SUWYf4lQboPDSAhr7WbKw562PNe8YdVepB3O1b6y9rBxMMh/7RJIhRkjCA7eEPiXXrLFE9L5YFRTBoUKxgc9uGV+Es0IVB+YHrxcntCfZ2D03VxP1Ng6vFLbyxjNoSy4MAlTqWtjG4qe2yW+/oQt/ZCzTc9Hu7r6QV7ggw1nxkosZICzHiG6UXfgtNLSWeu3w== 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 Thu, Apr 3, 2025 at 5:00=E2=80=AFPM Andrew Morton wrote: > Were any runtime benefits observable? I had replied as follows on another chain related to this patch: Yes, the patch reduces IPIs by a factor of 512 by sending one IPI (for TLB flush) per PMD rather than per page. Since shrink_folio_list() usually operates on one PMD at a time, I believe we can safely batch these operations here, but I would appreciate your feedback on this. Here's a concrete example: When swapping out 20 GiB (5.2M pages): - Current: Each page triggers an IPI to all cores - With 6 cores: 31.4M total interrupts (6 cores =C3=97 5.2M pages) - With patch: One IPI per PMD (512 pages) - Only 10.2K IPIs required (5.2M/512) - With 6 cores: 61.4K total interrupts - Results in ~99% reduction in total interrupts Application performance impact varies by workload, but here's a representative test case: - Thread 1: Continuously accesses a 2 GiB private anonymous map (64B chunks at random offsets) - Thread 2: Pinned to different core, uses MADV_PAGEOUT on 20 GiB private anonymous map to swap it out to SSD - The threads only access their respective maps. Results: - Without patch: Thread 1 sees ~53% throughput reduction during swap. If there are multiple worker threads (like thread 1), the cumulative throughput degradation will be much higher - With patch: Thread 1 maintains normal throughput On Thu, Apr 3, 2025 at 5:00=E2=80=AFPM Andrew Morton wrote: > > On Fri, 28 Mar 2025 14:20:55 -0400 Rik van Riel wrote: > > > The current implementation in shrink_folio_list() performs a full TLB > > flush for every individual folio reclaimed. This causes unnecessary > > overhead during memory reclaim. > > > > The current code: > > 1. Clears PTEs and unmaps each page individually > > 2. Performs a full TLB flush on every CPU the mm is running on > > > > The new code: > > 1. Clears PTEs and unmaps each page individually > > 2. Adds each unmapped page to pageout_folios > > 3. Flushes the TLB once before procesing pageout_folios > > > > This reduces the number of TLB flushes issued by the memory reclaim > > code by 1/N, where N is the number of mapped folios encountered in > > the batch processed by shrink_folio_list. > > Were any runtime benefits observable?