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 23D92C36010 for ; Fri, 4 Apr 2025 13:31:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 117C1280005; Fri, 4 Apr 2025 09:31:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C56C280004; Fri, 4 Apr 2025 09:31:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8158280005; Fri, 4 Apr 2025 09:31:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C78A1280004 for ; Fri, 4 Apr 2025 09:31:11 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A72731201A9 for ; Fri, 4 Apr 2025 13:31:12 +0000 (UTC) X-FDA: 83296447584.04.6CB6BDA Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf04.hostedemail.com (Postfix) with ESMTP id BC0DF40018 for ; Fri, 4 Apr 2025 13:31:10 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=W67eQdnn; spf=pass (imf04.hostedemail.com: domain of vny@google.com designates 209.85.128.174 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=1743773470; 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=9j9dv6GXiPC7vj8MzHNv36+V4Ok6JUP/IK7x4RgaiKo=; b=GHUCfgDT9ulDQl/pt9Bk56Cn16bgnJG3+bTarX1exltGNvWVjcfdNILdV41/hWFaSsEOjb /ODdBCwsaXh8Jb83r8h5iSLtYxU0oNYgi+UbjyYLFOSvQpOX5BaL5ZLQS6MBxjIhH7jhc+ loFvLPC1QxHUH4mJeAOtNEEnbJAgc4g= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=W67eQdnn; spf=pass (imf04.hostedemail.com: domain of vny@google.com designates 209.85.128.174 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=1743773470; a=rsa-sha256; cv=none; b=yvOU77tmjIxiHUvHmUAd7RfEKj7IaNIfPtTBF9Njej/d91Tlb/tpsZPt5LDcAJ1x4eJTIZ jtG6FQ8oNt7hoLLEeIoAFulDRP4LJ7oKFbz8dmN0HgCgTt8v7w8VFipiMHfPUKkPb4X0R7 LOD+N+wpKiuLWSTAtpoXNhU8S/oWoQo= Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-6fda22908d9so14987477b3.1 for ; Fri, 04 Apr 2025 06:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1743773470; x=1744378270; 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=9j9dv6GXiPC7vj8MzHNv36+V4Ok6JUP/IK7x4RgaiKo=; b=W67eQdnnmgOCjwaU76g8N3Ja+/qQfAw514eDWBZcr6cCOljbBoBQMfh6Sa/G5ifXtg KRCFirjYa7iNQaabaAGqgTP/vIPJSd22CuhN96tUctVIz9UMywtf1XYIiHgRg+caDdgM FCu7KSnHrMI2hT/pyu5r/8IJHGi77hgCerzFGgl38eNqkF/7j8GVrv/0BTYcbYIcw6P7 6q9ynE0GuxdZCxFY+miwk9q2Ww2n6395GIFvJjifG+fhQVuFGbvtRUqY4E+45A3r1l2u Zh7ToABzkaA4I8QlCWmz5ZiiDebKjjy/PME1JW6FkS9dMsCH5AVjldvepmuSrW136Rfp 4L9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743773470; x=1744378270; 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=9j9dv6GXiPC7vj8MzHNv36+V4Ok6JUP/IK7x4RgaiKo=; b=fsZ4RnvxQFYOHPuAEYfrZweXeq+HhHiam7unxWbQ8QJmuyp4QUywbHfz/rgH7mJAmr tFlEU0RKycUKvXL/PgP6b6iUyltjzdM7CF9Ol+OKOC75Acr+kyM4mR7TyVgCB3Hqn47S kK40T/gdqNt5rME/BvLNNuspfiKXL7u2qr13JMmTy1TMQCXI8bfqXn6TTcYz1vPlpR4J 08CjnrSLnESF+YcRAECEKAF6lDlItExNZSwEAL7RsLojuGWmY++KW0I43ZiufbpEhCPQ JJfcRl7hOtXTTxeim6wqmHQe9jSvZBZVbDulvKkn1NWH2qdiIiybYgfMR6W+z1jYA8GJ uxuQ== X-Forwarded-Encrypted: i=1; AJvYcCUnDmT5Kbz4XP0UtFcH6dHFwY/dxu7h6Eu3xEQ8pdv2uHvOlMh1YC8sWYjMZ7L3wIZDlrISXDa2Lg==@kvack.org X-Gm-Message-State: AOJu0Yw5pMiRSNyARi0zw0FfefYTr6NxqY/I46nuElj0RMg77cmhSGnx xsSU0LmeIIWNjzTEgWRDMh7XE5vNzlgBgbT02oTOoR/Lx7WhSTzQSfUhxAQeT2ie6j261Tf40bR JfnHDEHNCndLVRpM+RPMyiVVHWPTqzjep4GZ0 X-Gm-Gg: ASbGncvcm5/FyG5+o9sKpyjSsMexZaOesSxZEjv0bcY8qiGtT8vinXSJoz8YPre8w0z mLji55WhMGwUd1DPSFtKp+UKnAl36NmmrgNwe85it+wlpKx5ZxyqjcmYgclS4egqIgoAg2YB9o2 0cyaWNSPRdx4CuqR7kRBLLZhQ= X-Google-Smtp-Source: AGHT+IEWG3sqbXnADP245BlSPNLCcBF3AQNecJJFESoOGeYsuj4HqstpBt4IMzqXFViP2hCmr2cipsGBzgQOvc1tIUI= X-Received: by 2002:a05:6902:2501:b0:e69:18e6:6939 with SMTP id 3f1490d57ef6-e6e1faa1060mr4100163276.45.1743773469599; Fri, 04 Apr 2025 06:31:09 -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:30:58 -0500 X-Gm-Features: ATxdqUGnbBPzRJuyAC-9We2amGDsV_VHvi8ZxYhYZmPExDfiZR7QsnkbWCQ0sxc 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: multipart/alternative; boundary="0000000000003a92d00631f3e60e" X-Rspamd-Queue-Id: BC0DF40018 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ywc38yzxn714gabw6x346xnsjz6s31dz X-HE-Tag: 1743773470-776784 X-HE-Meta: U2FsdGVkX19I7ki9+7K5LU5X/xvVBJd4bw/fPRTexltql5/AwtwMAdlI9bUBZNW3mS+9dUeX/6EXThdfvl0E8rCppjpMUdjLcvwTF+2oKKFMmTxyLsgCAt4Ura0FY5WYPsahAtY04AQZvF/S3JRXyUPN11uXmIyRlyNWsuQmpQa82HmSMaTZ9vbWWCsPcg6fxzNscbnEdEQHSHRpTgzJLm4b94oyqdc11bW6CULUbVulfK0J+Cd+qfNL1coSykeYXxZNldg1sr/Vu1+9PYzhnNOsG+qJsRQqzYlIpewX4MPZvV4YHRmZsavPpPWsTFH8WWDOjpe/MZ9hZO/EvvQGE7vbzqUloB+T4L9CCBCLoXLPJGj+lRzfaspfngb1FSXLejHkGES1uYhovVzqkAGOdrzB6IX7Jr6TPi9uO37jtO55/ipYykFnsl6PfdPb5AUEnyVEAoA+fVYi8/Nce0VBCPQ5ymJNAYxaxsl+AfVzhBNr4/HR2PuiLD3CgSKmJ7whUO/PmX0BYZ6qycWVj2LIyjpdeolWaqjCfgpWOmCzO/jybH3C56z64yQyE9hMjRA6dPzYhvVWvmZmrf7/J4+7HqRplD0O8fvpWqTxPaExCT5jLB2lMkIQpxPZywVbZrQ+74aL07eOcf7/SuyypuCeoGTGTO439r6LH9vP/nMUdaiEvViku/VvtNDywAQ/j4N9muPeFfmoOLkWEQaG+1KyuiVtc3ZSJ0Ds6sZHVmzB7ISMhyCupZLRl6y8y9Qr+JXUJBW/5Yjk6NQKQ43rZEnEJkB7xX0HPVDCrJStkFgbUlWgjFOe2mxfbe0qcCm2U3nCd+RLuUeQXEGEycN2APIpguBsbhcSCzp5VFowxH6VStNhi0Kpo6HDFxno19bGbuNPQVwFAJZrbSR/S7XwetvlDMxPu5zd21neRFFUZdogorg+qhCxxYqlDwozlraGimBP9iHL2Yn4P0Em3Tziye4 zsd3GxnF qVd6j2AiM0S4HDVon71sxK7mohGv7MM2mSeISkpXKnsueXGilg3bdLP01tCdDr/yHIBslUEozHqxi8RVf7D8VBLle//b5hSLVK26qShbqzC15FXb7vpFXrYU1Rt3HYrrJUFqF5dLscN/kVgvUjgDCCzmt3h0SF4UrkBtFilQFtkqH/X2sD5ASDwHsjd9ACBmZUcIqbSosko9t7eDcTqh6EZfqeP1mUr9Ozoj4PHR4jfVjFG9P3Xeu6GW/od9YeJVrQuuM1i+41X/DdSTJrnrrqtxi4pEAKaVoBlcKLvFYOycvBMv1ss98ysnAGBqAMhB1nO6qGYwz4rbOQJvY/1ZpC9+NBlfWGkFtBEB8Ht8fn89OXzM= 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: --0000000000003a92d00631f3e60e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 --0000000000003a92d00631f3e60e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 3, 2025 at 5:00=E2=80=AFPM An= drew Morton <akpm@linux-fou= ndation.org> wrote:
> Were any runtime benefits = observable?

I had replie= d 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 shri= nk_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
=C2=A0 = - With 6 cores: 31.4M total interrupts (6 cores =C3=97 5.2M pages)
- Wit= h patch: One IPI per PMD (512 pages)
=C2=A0 - Only 10.2K IPIs required (= 5.2M/512)
=C2=A0 - With 6 cores: 61.4K total interrupts
=C2=A0 - Resu= lts in ~99% reduction in total interrupts

Application performance im= pact varies by workload, but here's a
representative test case:
-= Thread 1: Continuously accesses a 2 GiB private anonymous map (64B
chun= ks at random offsets)
- Thread 2: Pinned to different core, uses MADV_PA= GEOUT on 20 GiB
private anonymous map to swap it out to SSD
- The thr= eads only access their respective maps.
Results:
=C2=A0 - Without pat= ch: Thread 1 sees ~53% throughput reduction during
swap. If there are mu= ltiple worker threads (like thread 1), the
cumulative throughput degrada= tion will be much higher
=C2=A0 - With patch: Thread 1 maintains normal = throughput
--0000000000003a92d00631f3e60e--