From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A043E1B6CE0 for ; Wed, 22 Jan 2025 20:05:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737576350; cv=none; b=Z+zmZbiHiNrYkQQ3INzhjqkG0p55zJYmHYhQ97U4f/frCoMrZOdD6BCTddPvgYa0383PRudRR9X89PkoPNLCcJrBxwWpoKtZzLiC2lpwiYCEyrJgSxKlXxPfmwj3x5GQ/2QSNLibFSgu5qYMaTcbegBLYfXaNutHX+wnox7OqOw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737576350; c=relaxed/simple; bh=uF+EtzEo1MBzJLul5VAqJp9o/IVt+jDiN49DXxj88ww=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=m9lEa81vSM9Pdq0lvHzQj1vPhGCkJZMtVTdJmGrHsO+i0soZ9dwu8/TXY6ldAoqfVTSxU1HYCSm+ybbxa9sq4uezYvrGZHQ8aJ/goMBR730PSw29AX5PMxH1Qk7wXoXDiKZ9XgTRejzN7JFncuuHfQkDIQJIGtbMvmg3+GRwqT0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sQRRo21t; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sQRRo21t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED0CEC4CED2; Wed, 22 Jan 2025 20:05:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737576350; bh=uF+EtzEo1MBzJLul5VAqJp9o/IVt+jDiN49DXxj88ww=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sQRRo21t8kFgZWwBiIylReXTe60KhxKy4y/iP9+aT1HT1rX9IBSQhBfSfp5puxidb p3M3wP02mrmR4TCXepnZ9DQspveAf8M3cAvdP7VIfHAOp0TSuq6Y7UB1BBXZOWFwHx 2FLT2HEoz/Hs6KsylfKqsJ52/wQZ3DHFb4vnia6YofokeKQ/RAmPtOMTMAw8Q7htEY /mAP14R8p3bj3s10aaE6DZgEgq+RdFrjxy/0nyHc8CVgo3TDsaBqvFVUCwtV0xOC0T +kxFi6IkvT6lWyZIrK29rDnXj2ERINN/wDSneEUi0BM3bHdkZbBkmNrAHWvS3oPGjA DV2kXJSnrGvBQ== From: SeongJae Park To: Vinay Banakar Cc: SeongJae Park , Bharata B Rao , linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, willy@infradead.org, mgorman@suse.de, Wei Xu , Greg Thelen Subject: Re: [PATCH] mm: Optimize TLB flushes during page reclaim Date: Wed, 22 Jan 2025 12:05:45 -0800 Message-Id: <20250122200545.43513-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, 22 Jan 2025 07:28:56 -0600 Vinay Banakar wrote: > On Wed, Jan 22, 2025 at 2:59 AM Bharata B Rao wrote: > > While that may be true for MADV_PAGEOUT path, does the same assumption > > hold good for other paths from which shrink_folio_list() gets called? > > shrink_folio_list() is called by three other functions, each with > different batching behavior: > - reclaim_clean_pages_from_list(): Doesn't do PMD batching but only > processes clean pages, so it won't take the path affected by this > patch. This is called from the contiguous memory allocator > (cma_alloc#alloc_contig_range) > - shrink_inactive_list(): Reclaims inactive pages at SWAP_CLUSTER_MAX > (default 32) at a time. With this patch, we will reduce IPIs for TLB > flushes by a factor of 32 in kswapd > - evict_folios(): In the MGLRU case, the number of pages > shrink_folio_list() processes can vary between 64 (MIN_LRU_BATCH) and > 4096 (MAX_LRU_BATCH). The reduction in IPIs will vary accordingly damon_pa_pageout() from mm/damon/paddr.c also calls shrink_folio_list() similar to madvise.c, but it doesn't aware such batching behavior. Have you checked that path? Thanks, SJ > > Thanks! > Vinay