From nobody Mon Feb 9 15:59:23 2026 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 684F21A0AFA for ; Thu, 19 Dec 2024 20:33:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734640447; cv=none; b=oMNg6XNHBSOunOFTYPfve/v1LbUdge/xbVoku11H8u8q4eZopGBYbI1dN6PU2rq4EmeuW/Yz61uB9zu49+7LbNEBoljLNLLW5Ku0InCF6/DnINyPH07Z2NFionb1VFWf6NV/G3L7jpYkOAi+yn194hHHkq1Pz5V3PeM4U5o1HE8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734640447; c=relaxed/simple; bh=Gm89c9mTqkQgIrTOH4n6vL95bgGByQ6X2tucB2xFGTg=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=MHRbBqpnBGART87JdE6GaZ0XnFjmafpaLr+Cen3Rz6utVd5zMlDgqfYlIlsUL5qyLaGht105DM+6qO3qU0IxTbjyOh6TPinPka7A3Vk+tULjaJAhEAUH067BfiQLHErBZavriG/Tw2QawpjsVtStk3j7LEhnp/MoFAMKNm+LLUQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=shelob.surriel.com; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shelob.surriel.com Received: from [2601:18c:9101:a8b6:82e7:cf5d:dfd9:50ef] (helo=fangorn) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1tONCY-000000002Ni-0at9; Thu, 19 Dec 2024 15:32:54 -0500 Date: Thu, 19 Dec 2024 15:32:53 -0500 From: Rik van Riel To: Shakeel Butt Cc: David Hildenbrand , Andrew Morton , Chris Li , Ryan Roberts , "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org Subject: [PATCH] mm: remove unnecessary calls to lru_add_drain Message-ID: <20241219153253.3da9e8aa@fangorn> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: riel@surriel.com Content-Type: text/plain; charset="utf-8" There seem to be several categories of calls to lru_add_drain and lru_add_drain_all. The first are code paths that recently allocated, swapped in, or otherwise processed a batch of pages, and want them all on the LRU. These drain pages that were recently allocated, probably on the local CPU. A second category are code paths that are actively trying to reclaim, migrate, or offline memory. These often use lru_add_drain_all, to drain the caches on all CPUs. However, there also seem to be some other callers where we aren't really doing either. They are calling lru_add_drain(), despite operating on pages that may have been allocated long ago, and quite possibly on different CPUs. Those calls are not likely to be effective at anything but creating lock contention on the LRU locks. Remove the lru_add_drain calls in the latter category. Signed-off-by: Rik van Riel Suggested-by: David Hildenbrand Acked-by: David Hildenbrand Acked-by: Lorenzo Stoakes Acked-by: Shakeel Butt --- mm/memory.c | 1 - mm/mmap.c | 2 -- mm/swap_state.c | 1 - mm/vma.c | 2 -- 4 files changed, 6 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index 75c2dfd04f72..95ce298dc254 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1935,7 +1935,6 @@ void zap_page_range_single(struct vm_area_struct *vma= , unsigned long address, struct mmu_notifier_range range; struct mmu_gather tlb; =20 - lru_add_drain(); mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma->vm_mm, address, end); hugetlb_zap_begin(vma, &range.start, &range.end); diff --git a/mm/mmap.c b/mm/mmap.c index d32b7e701058..ef57488f1020 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1660,7 +1660,6 @@ void exit_mmap(struct mm_struct *mm) goto destroy; } =20 - lru_add_drain(); flush_cache_mm(mm); tlb_gather_mmu_fullmm(&tlb, mm); /* update_hiwater_rss(mm) here? but nobody should be looking */ @@ -2103,7 +2102,6 @@ int relocate_vma_down(struct vm_area_struct *vma, uns= igned long shift) vma, new_start, length, false, true)) return -ENOMEM; =20 - lru_add_drain(); tlb_gather_mmu(&tlb, mm); next =3D vma_next(&vmi); if (new_end > old_start) { diff --git a/mm/swap_state.c b/mm/swap_state.c index e0c0321b8ff7..ca42b2be64d9 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -317,7 +317,6 @@ void free_pages_and_swap_cache(struct encoded_page **pa= ges, int nr) struct folio_batch folios; unsigned int refs[PAGEVEC_SIZE]; =20 - lru_add_drain(); folio_batch_init(&folios); for (int i =3D 0; i < nr; i++) { struct folio *folio =3D page_folio(encoded_page_ptr(pages[i])); diff --git a/mm/vma.c b/mm/vma.c index 8e31b7e25aeb..d84e5ef6d15b 100644 --- a/mm/vma.c +++ b/mm/vma.c @@ -398,7 +398,6 @@ void unmap_region(struct ma_state *mas, struct vm_area_= struct *vma, struct mm_struct *mm =3D vma->vm_mm; struct mmu_gather tlb; =20 - lru_add_drain(); tlb_gather_mmu(&tlb, mm); update_hiwater_rss(mm); unmap_vmas(&tlb, mas, vma, vma->vm_start, vma->vm_end, vma->vm_end, @@ -1130,7 +1129,6 @@ static inline void vms_clear_ptes(struct vma_munmap_s= truct *vms, * were isolated before we downgraded mmap_lock. */ mas_set(mas_detach, 1); - lru_add_drain(); tlb_gather_mmu(&tlb, vms->vma->vm_mm); update_hiwater_rss(vms->vma->vm_mm); unmap_vmas(&tlb, mas_detach, vms->vma, vms->start, vms->end, --=20 2.47.0