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 E21C3C02182 for ; Tue, 21 Jan 2025 18:03:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 567936B007B; Tue, 21 Jan 2025 13:03:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 517DF6B0082; Tue, 21 Jan 2025 13:03:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DF526B0085; Tue, 21 Jan 2025 13:03:37 -0500 (EST) 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 203366B007B for ; Tue, 21 Jan 2025 13:03:37 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A4C3F1C7F5D for ; Tue, 21 Jan 2025 18:03:36 +0000 (UTC) X-FDA: 83032231632.19.F086894 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf18.hostedemail.com (Postfix) with ESMTP id BDD8D1C000D for ; Tue, 21 Jan 2025 18:03:34 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RP9Y+b88; spf=pass (imf18.hostedemail.com: domain of vny@google.com designates 209.85.216.47 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=1737482614; 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=kZND2G1lJyBLewkbQO0OPawaIj7C/DiYHIIVDiX44Cs=; b=z/TpgHIh2R3OLOPPniKtUAVwpMEkJKysfGvewt8LrdbdNlNEJDJeOrtGCxaxxZbmI1useQ aC0aRB2+L5g8fzVoDQzbEKIr2TM+ze2bsd0RHh9txW9ytIp48zFGll1czEbj51iHW2/cq0 c55+/asne3FNehC04EVMw3o3ow2LBnY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RP9Y+b88; spf=pass (imf18.hostedemail.com: domain of vny@google.com designates 209.85.216.47 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=1737482614; a=rsa-sha256; cv=none; b=SjhvWvsLvIQSwMiJVt/wco6nJWjOTrJ8R8fQzjwDs0WpoX5L/P9Yc/iGLRKN36Mp1mGl+N EJ11FVs1my3xLNvhYbismj4XqR8gsMsdPIWLwgK+F4P0xJx1eRIdYQR6tVNbjtnvkEKWKO ZRY5NlRtdcxdmpF0DsekcQRHj/Tb+vM= Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-2f43d17b0e3so10796789a91.0 for ; Tue, 21 Jan 2025 10:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737482613; x=1738087413; 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=kZND2G1lJyBLewkbQO0OPawaIj7C/DiYHIIVDiX44Cs=; b=RP9Y+b88pYwOe8aUjsn0J9+zvFqjSNlh5o9At0re8yZN3boGLgjxcgwbmbqrvgaS+2 ge23ZevmzGoa3B6jhak/Mxo/KAIQOVA3dvhKHsoMB1q5JFAdzs+JPNavJu7RFd6bVV1R nK43AQHIRGr3KjQmI4IQ8/ULb209u4Odj97i8juGSEzzhpIo31kCgmw9Y8bm/c8zknBp LwUmWjVKy72L3bz9HJ3+zlLY7MzP7QhaQS8efjRihGi6FzWVIUZX7lzUobFjZG7ViT5Z rykSONDeDoUDI/R7bAvJbegqqdPaUeS05zx8yn1VD6nrdFc80VndxjknyKucxanwP11W XmiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737482613; x=1738087413; 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=kZND2G1lJyBLewkbQO0OPawaIj7C/DiYHIIVDiX44Cs=; b=wGVsrHa6eDmrkvUWbF8Mw25ZZOd8aroFhZ7L6PE9/Cuq+D068YgTlmLuqHhNlo1zFi TQfrn+5LlrXizM5irRbYlX5Tm4ibsFCOQuqyRRDS7+DNNFOOVNPvSb3tcvvxfdxjUI7N QNZ/yoFh/inJLVmq66k8202MgQ/O6RmXt7YmtEUqCAh52ON+fuQSBMObVvtJVeAM8aTi wdSZSF35sN4YYbmBedNNcYwxjbbGmDXQsDsDBqQyfl2pTrsF6vs0zK4RRfk7IlLTBaLP SMv4/sjg8f3IE3LF7RcxJsieMfuoHoWPGf7Ave7cZSJzvTCLbFK71tMuPV49o2Q/yfj6 dk7w== X-Forwarded-Encrypted: i=1; AJvYcCXEBtbhRoKSeu2R6wNvUHaT+mEwzqLtneJLk4VLCZuh9rjy2f9MmuoSw9MMCvRB9Di16bKt+9XlHA==@kvack.org X-Gm-Message-State: AOJu0YwQowv5T1Ua9+K5kzXz4QB3Kkj8Nncgxm3Kk7qFqp2HA/3gpYws 6BSwhNhXuWBmNlgUOvmJdeiNwFmTOx59Sc+cURtz4S9cbmb2BLCqgnKR1eci9RehC6ovUiJt+We QgVhJ0rFao5WySaYa9AJhHrWpukWRXS1dgE6M X-Gm-Gg: ASbGncs7wu3H/GqiTu3oZt0h5Nu/8wV2zZeFPzCk6qUS8M5LKIV6g8+1OUIYtQIaDRN b1AsoMbLu32RoY35iYLDORhoEJtmiOaJKDihWSN9XL16twoe+Qvg= X-Google-Smtp-Source: AGHT+IFoa3O6nKhYDUVzVLZx8MUW1AQxW7Ru+fGgE1y5+R17ap75lHbu31y1gJ8pw+Ao72ZuXJh3s+gGkPB2+ZYFHZM= X-Received: by 2002:a17:90b:3bc3:b0:2ee:9b2c:3253 with SMTP id 98e67ed59e1d1-2f782d97961mr27521059a91.30.1737482613199; Tue, 21 Jan 2025 10:03:33 -0800 (PST) MIME-Version: 1.0 References: <20250121014359.GA60549@system.software.com> In-Reply-To: <20250121014359.GA60549@system.software.com> From: Vinay Banakar Date: Tue, 21 Jan 2025 12:03:20 -0600 X-Gm-Features: AbW1kvZ1SmqMpqEE96uAtpwzfE40JVhDyRBqyaRWmu9KZlrcVVJLFi3iC5XMxqo Message-ID: Subject: Re: [PATCH] mm: Optimize TLB flushes during page reclaim To: Byungchul Park , linux-mm@kvack.org, linux-kernel@vger.kernel.org, willy@infradead.org Cc: akpm@linux-foundation.org, mgorman@suse.de, Wei Xu , Greg Thelen , kernel_team@skhynix.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: BDD8D1C000D X-Stat-Signature: p9tkskhwgammw8cxmj9y9ew43hxqqnxa X-Rspam-User: X-HE-Tag: 1737482614-227754 X-HE-Meta: U2FsdGVkX191OHrmCC7ERl45IA9If0LQahYfrc/qt3vQYWw6jCJN43gQvKFOc2V127mDvgVzHXDbqjdGQmVkUZz6CkhP9Mt7ACZXSqsRvJcYvMfgOs7zm6y3nOKyUF9/W9FE3poGzMRfsPLlw/k0j0brsq5ldwQxZe4GTIjSF1TDgjKVSBjoyZQihh+NTLAGUDPywKPvCjGkLVmOGTDr8MFZoI26arsXWHdswBJ8DQgwNRmiCjMesRq8lx53Z6lCsVgbxNG5sTU5CJZNV5KMsBeq3osGdt6HGe7PMoLuQeHCr2dCZXhQv8rp4K5mhK43gOr0/lIqGu7iYkvjoI4pBJ/x1HTRp3paRfr7X9YeBkYK/2joS+05WeoQjxSTV8oQWi8R7uFBARMsbWJRc+FRnk0yVu0u7t7htfhzs4kXBQhDPmnFZhOuK7ABOTlzXmYIF6nK+7DP42FYZywXWPDPWtGdrqv0TsQy2hYQrfgYZKZEEjdO8ctK/8dZHlaPjT6lvIqek3zNT9kZ/LlM6BMMBvbCeyoI0tTn0aheVuT5x1U8gDXhXpaWUHe73jqzrFSr7UOVUduOqXsI96aYLCjsu1RSH4kZD+a9Sbt8780NVbIA8v7qppvM+1JQCb7do6lTHot+/zAVcrgBRWokr56c9ja1PwJVKKqxhdyCq1rBmtIN8pH9Pw5wHdajHbj7UIpTUYNbRnZX24l8ZgGmyJGwDRWAXk53FskzAeoyAkGBvIwcbg3xLXh7Av5yN6MguAaAFeSaOskXzJ3zGyS0Sd8gw/8Emq0lEmxgWPrYgg/hcXRl3JB3V2MEBPqz9YgP+ss5WKUoaWsvnP0KTWdraOjWESBGxSxk7XDmY3PUzVvvTk9NF61zpjEns7AC+DiR6bKsu69c17xhAOHbWdw6WEjtYIInqxOE9HmF+FDj6UeGY5z4rq8fkq+QKfezxsaXcirX2noz/RY/37hNR4MUItU fPvr8F59 0S9RwifrtWMhfdfgg0V0dyPOmtilfJ8YSX8+uP/s6/XrShUv3yO+fSgBsq72orMUsqqhbWrgONFQjaPKzvQLdvBdiJks5X9Df+5pveKOPXqzwsGAPFgASIM1Shy5BbywFCuUZg2TsaTHhpGNJa9jtU1M3iXpY6MJ6p1wxbZhxGRsjU6tzQYZ7QGdxJbJvUjjR5SrGzhzsmS/dbq7rf69JQBO4HjGCUBvVXGr1Q3CXqnvgYhYgz4C2mvEmTBsPp2J3dH+V X-Bogosity: Ham, tests=bogofilter, spamicity=0.052242, 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 Mon, Jan 20, 2025 at 7:44=E2=80=AFPM Byungchul Park w= rote: > The *interesting* IPIs will be reduced by 1/512 at most. Can we see the improvement number? Yes, we reduce IPIs by a factor of 512 by sending one IPI (for TLB flush) per PMD rather than per page. Since shrink_folio_list() operates on one PMD at a time, I believe we can safely batch these operations here. 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 I expect a similar application performance impact when memory reclaim is triggered by kswapd.