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 950DEC0218B for ; Thu, 23 Jan 2025 19:16:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1500D280010; Thu, 23 Jan 2025 14:16:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1001028000C; Thu, 23 Jan 2025 14:16:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F098B280010; Thu, 23 Jan 2025 14:16:32 -0500 (EST) 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 D09EC28000C for ; Thu, 23 Jan 2025 14:16:32 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 79D91804B4 for ; Thu, 23 Jan 2025 19:16:32 +0000 (UTC) X-FDA: 83039673024.28.E11CE41 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf02.hostedemail.com (Postfix) with ESMTP id A272C80007 for ; Thu, 23 Jan 2025 19:16:30 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3cWibGsX; spf=pass (imf02.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=1737659790; 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=KZhr/ZxpLXoY3gtxxNkA2WzJ3Fnaj7XIfZzYMtVtUIE=; b=l9C7bX4tSTrdE2T7/g1dd9EUYE3QYHi/3jU0DSjIobOU4E6LU4/+x6oxLirjBLL0/X4MWA Ind0TJ+K5qE2kN4wy1wlyWB0VLkf4bs/PA8mIYiKeT2ILx/DGOymOjFZeJD4vw/G/irYSg YE/xbXmYafv7nk0ZqBtULWaRMaNq6XM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3cWibGsX; spf=pass (imf02.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=1737659790; a=rsa-sha256; cv=none; b=x1Diq8Xsqg/GP5eUxI0YWkPTbWHSjDcKDeEMlx58LPME9agpiAQCcRTWNfgr1rtHbl65wm 79buv9KbXsp1S9+Laq+nlH7bEzR1tpy1F+GjALgSabrl+Ee3IUq5hOhQVWbbBG/9jheZ7d eyPWlscYhxdFNv+eVqOigybBYrY7tqA= Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-2ee786b3277so1868074a91.1 for ; Thu, 23 Jan 2025 11:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737659789; x=1738264589; 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=KZhr/ZxpLXoY3gtxxNkA2WzJ3Fnaj7XIfZzYMtVtUIE=; b=3cWibGsXjlhYUTcQZ7FEz/W0pQf2VA81JmkCqWmFw6H7Q2JX46/tqqY1w6da2TAFlX uvK2fzxjwCnnpg6dhnv2YaQBc+lFOy9o3jfiaxTEssjhBaF8/Yk8LXWfcbgq369iKfiO SssQNqvCRBRAhRIVcRUxtqLpQ/cvHf9m0tnPwxnTCb5XqDR6duaQWHGIeisvy2Us+0yN G9WheQ0m5c4pf4X39QcLAT6c/jZgw58ExS8qwnQsv3H1Np5imYw7LsndZn5eDH5n2FFb Mwg5EVDQm80ICkM5czR9tQHuubhh5tXA3uaVCCQ07KCeJciE96yCo64AkVxe/XCG75XA RNow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737659789; x=1738264589; 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=KZhr/ZxpLXoY3gtxxNkA2WzJ3Fnaj7XIfZzYMtVtUIE=; b=mjVqtc5w3ohj+XNJDZR11jEvJqRGglZTVnauMIAxzMmWJpC7jAeh674mmPDdtKget5 qHj5EU12nmwDBPnmz4YLshPsJzlEZyM6X7SY4L5mgJuA3M4qhHzTcjEGIkn439plrHna nLeXCwOrWoRp9LnGYK1q44u91MWR9a4oJ0Yiny0126PysUZcRqH0o50pqrtRWDtE8Dga R2GLt4IE5ieey/FK6WbKt53nSWK56+XrquFtRic5BKO/CN/UtVIDYhyS2lXIdMCcY0gw xq4H/f8bbvBcj8PRJ0rTzXRNk8Z8l0BMuh142S+/H7wAYxHInrpjUxxfmUCtwSyQbd3X Wb8Q== X-Gm-Message-State: AOJu0YyaL0av/J/mZRoZSToL8ADoaUxeTSSINc+ECARwiB6F4P6zbQCk Cs0Aata2mMsgT9uAKXlcBpXeoCY+G+8auvudZjgL3660W087AwNy7MG7zdCuJz7M8XfM7URKmL/ HfZ9rWpxsUyq39SDfPQk3AZyT8pF+AnYsTqCB X-Gm-Gg: ASbGnctmpMbro60E4LO5wCYrJO8P3e5x8vnR0SiX9vrBugbdwC1tSro412PT9J2s8SY gTFw3/NDlgFOO9hykXuyZ6HPE5TxSU9xfiPzZj/OBHyXiUPMEHeeJ6DgMvlBASf70zAho X-Google-Smtp-Source: AGHT+IGL7fzgExwD303QNU9zc+ZEulJD5AhOVmtEHnmiL6Focz3LqZ/W/FwQ4+qCgeihXiJPG903QU7PZsvv1TSeCmE= X-Received: by 2002:a17:90b:2e41:b0:2ee:b875:6d30 with SMTP id 98e67ed59e1d1-2f782c779d1mr39636595a91.9.1737659789134; Thu, 23 Jan 2025 11:16:29 -0800 (PST) MIME-Version: 1.0 References: <135b6d6fad6083bfd11a9dc98fad69756b51c59d.camel@surriel.com> In-Reply-To: <135b6d6fad6083bfd11a9dc98fad69756b51c59d.camel@surriel.com> From: Vinay Banakar Date: Thu, 23 Jan 2025 13:16:16 -0600 X-Gm-Features: AWEUYZmgJyaHvl38ZkHs8UyzZ52d0Grd870lTyYyEghIOxpv27kl-e0e6guAvso Message-ID: Subject: Re: [PATCH] mm: Optimize TLB flushes during page reclaim To: Rik van Riel Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, willy@infradead.org, mgorman@suse.de, Wei Xu , Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A272C80007 X-Stat-Signature: ora7ykymmpy1uaqbhda7uzowhmpnw9mi X-Rspam-User: X-HE-Tag: 1737659790-277220 X-HE-Meta: U2FsdGVkX1/zwtAAGBejMi796hxunDcQ1py4KXVUG2wKCfZ9GoeJ5ObCl0zuWdh8Oy6pYLUnA+3CpFfVPO473MbzQ8WVLgfO/36V0T+kCwaxbxEYI1QaKEYuyWl00mp8hS+c67ChOENnPLSxxI+oDvWKr0T45wHNgJsz4DbpELDPQX3EH46iFU/dev7T1ey47y76xDYp8DhTHAmeiBnC4dbm6uulunxtWXtQ5diXLXP0Pnhcm4/v2dojJmpyNaoBqfApp2+d0nURhb4P1jC0M+LHmLov+HipqFBq4BFLDJXTXYDLnO4SpAXk/rNyvjSEkLngnSxGdzXvX+ZYg73hpYt/xKqmD/NR9oJ1W9h/nltCBb6H2nwFpwvUKnqLqy/yldBgBJ7LrTZWabLHfsnJFbS+HMz4YbzWWfP94KpOkz9aB4J8I3IbWUoNT7NYfdn+5pmj/LKpvNQTwwphV/k464woaJH9cmBW+5Uae0lmpKxd9fnOwt+2790p08IocTFW9iPgIycbP26HMAgDFwG5wabiH/4kXpgMMNebk/WqtpZ3avWIxRCk755oNdvvD/ODqt1JXcXsfoPd+szlX4W6rL/N/LR7qQuZXviyeIYhDjl3PXoc9mdYykcoVNb1X2rdUqN8lX8hX6oeuPuFFH8yvXO14Y0GNrFBAPMKn+Krng3PPHMB+iQZj/DJiuEAcnS+Yc+sqa3cfDsGYb9xsj9noOEpU/lfF7H9FWKsEtLGbNJfL6RyeakMrOoOwkTvY3Fp0iHxvHj7yBR8dLE8UL3XylAYpqVXMKZMe+k58C5JVESz3A9ZDUeWlYOdnnxZJMnZttLJxbtD2HLU5cIqMW9HImxzLRdMhJBPNgxuBH2ZjFNsZpnk1DRsotilxiZHOSq31F+2R9pIXYJBAEZ6MbHu+NtpmppBuR0vIiWKdxTjTCuyek/NeF0kaeXrUi1yT5pB17LNbJYmE2W0AwHv3kM Jeivo13W 2Ytw5R1ldN6fbYZxLI4IsMohvBZKKEmqns9nnYwIt7jCrU3/woR/NckhLhIe3odcZxtqZ+hk88ak3QZmt32ZZvnOOifu0bDBn0w417uCLy1IIy9tdr5Al889+1O6u61nby2OQG80Zk5RWQbqlsooPuZN3gPoT5hCb+asBCWqgjdiJeXF7Aps41PwuAhCHAVSqaFUwcE7dFIXlOzxuA//lj2D0FYT6SWURWLJS68xCvxY2Z0nrZxRHm/Jq+Anie0qT2JBS X-Bogosity: Ham, tests=bogofilter, spamicity=0.000190, 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 Wed, Jan 22, 2025 at 10:20 PM Rik van Riel wrote: > I see how moving the arch_tlbbatch_flush to > between unmapping the pages, and issuing the > IO could reduce TLB flushing operations > significantly. > > However, how does that lead to PMD level > operations? > > I don't see any code in your patch that gathers > things at the PMD level. The code simply operates > on whatever folio size is on the list that is > being passed to shrink_folio_list() > > Is the PMD level thing some MGLRU specific feature? > My main quibble is with the changelog, and the > comment that refers to "PMD level" operations, > when the code does not appear to be doing any > PMD level coalescing. I initially assumed that all paths leading to shrink_folio_list() submitted 512 pages at a time. Turns out this is only true for the madvise path. The other paths have different batch sizes: - shrink_inactive_list(): Uses SWAP_CLUSTER_MAX (32 pages) - evict_folios(): Varies between 64 and 4096 pages (MGLRU) - damon_pa_pageout(): Variable size based on DAMON region - reclaim_clean_pages_from_list(): Clean pages only, unaffected by this patch We have two options: 1. Keep the current logic where TLB flush batching varies by caller 2. Enforce consistent 512-page batching in shrink_folio_list() and also convert to folio_batch as suggested by Matthew > > I'd appreciate your feedback on this approach, especially on the > > correctness of batched BIO submissions. Looking forward to your > > comments. > Maybe the filesystem people have more comments on > this aspect, but from a VM perspective I suspect > that doing that batch flush in one spot, and then > iterating over the pages should be fine. Thank you for commenting on this! Vinay