public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated)
@ 2001-03-22 22:21 Richard Jerrell
  2001-03-22 23:16 ` Rik van Riel
  2001-03-26 14:26 ` Stephen Tweedie
  0 siblings, 2 replies; 10+ messages in thread
From: Richard Jerrell @ 2001-03-22 22:21 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1006 bytes --]

2.4.1 has a memory leak (temporary) where anonymous memory pages that have
been moved into the swap cache will stick around after their vma has been
unmapped by the owning process.  These pages are not free'd in free_pte()
because they are still referenced by the page cache.  In addition, if the
pages are dirty, they will be written out to the swap device before they
are reclaimed even though the owning process no longer will be using the
pages.

free_pte in mm/memory.c has been modified to check to see if the page is
only being referenced by the swap cache (and possibly buffers).  If so,
the buffers (if existant) are free'd and the page and swap cache
entry are removed immediately.

Essentially, this is the same patch as before, but there was one condition
in which case we would leak and extra reference to the targeted page if
the counts would not allow us to remove the swap cache entry.  The leak in
2.4.1 also applies to 2.4.2 and 2.4.3-pre5.

Rich Jerrell
jerrell@missioncriticallinux.com

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1499 bytes --]

diff --recursive -u -N linux-2.4.1/mm/memory.c linux-2.4.1-paging-fix/mm/memory.c
--- linux-2.4.1/mm/memory.c	Sat Jan 27 22:12:35 2001
+++ linux-2.4.1-paging-fix/mm/memory.c	Thu Feb 15 13:36:06 2001
@@ -281,6 +285,34 @@
 		return 1;
 	}
 	swap_free(pte_to_swp_entry(pte));
+	{
+		int num, target = 1;
+		struct page *page = lookup_swap_cache(pte_to_swp_entry(pte));
+		                    /* returns the page and takes a reference */
+		
+		if (!page || (!VALID_PAGE(page)) || PageReserved(page))
+			return 0;
+		
+		num = atomic_read(&page->count);
+		if(page->buffers) target++;		/* 1 count if we have buffers */
+		if(PageSwapCache(page)) target++;	/* 1 count for the page cache */
+							/* 1 count for our reference  */
+
+		if((num == target) && PageSwapCache(page)) {
+			/* SwapCache entry is the only thing referencing this page   */
+			/* (and maybe buffers) asides from us, so to prevent it from */
+			/* sitting around and wasting time/memory, throw it away     */
+			if((page->buffers)) {
+				if(!try_to_free_buffers(page,1)) {	/* Can't get rid of buffers   */
+					page_cache_release(page);	/* get rid of our reference   */
+					return 0;			/* and let someone else do it */
+				}
+			}
+			free_page_and_swap_cache(page);	/* Expects the page to be mapped, so will */
+			return 1;			/* account for the reference we have      */
+		}
+		page_cache_release(page);       /* Remove our reference, we can't do anything */
+	}
 	return 0;
 }
 

^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated)
@ 2001-03-27 21:29 Richard Jerrell
  2001-03-27 21:18 ` Rik van Riel
  2001-03-27 21:51 ` Linus Torvalds
  0 siblings, 2 replies; 10+ messages in thread
From: Richard Jerrell @ 2001-03-27 21:29 UTC (permalink / raw)
  To: Stephen Tweedie; +Cc: linux-kernel, Rik van Riel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1901 bytes --]

> fork and exit are very hot paths in the kernel, and this patch can force
> a page cache lookup on a large number of pte which wouldn't be looked
> up before.

True, but I don't know how large of a performance hit the system takes.

> Given that the leak is, as you say, temporary, and that the leak will
> be recovered as soon as we start swapping again, do we really want to
> pollute the fast path for the sake of a bit more speed during
> swapping?

It isn't speed of swapping that is the biggest problem.  The problem is
that if you run a memory intensive task, exit after being placed on an
lru, and run it again, there won't be enough memory to execute because all
the memory you used previously is now sitting in the swap cache.  That
isn't to say that without being patched the speed isn't poor.  After all,
we'd be paging out a dead processes pages.

But you are right, this fix is slow and that can be improved.  So,
hopefully this patch is satisfactory in respect to speed and fixing the
leak.  And will also remove the panic which is possible with the other
patches (can't do a lookup_swap_cache with a spinlock held).

Instead of removing the swap cache page at process exit and possibly
expending time doing disk IO as you have pointed out, we check during
refill_inactive_scan and page_launder for a page that is 

1)  in the swap cache 
2)  is not locked 
3)  is only being referenced by the swap cache, us, and possibly by
    buffers
4)  has no one else referencing the swap cell

If that is true, we can safely remove that page without writing it to
disk.  In addition, the number of swap cache pages are included in the
amount returned from vm_enough_memory to get rid of the temporary leak.

So, the exit path remains unchanged, reclaiming a page is faster for when
the page is no longer being mapped, and the lazy reclaiming for multiply
referenced pages remains intact.

Rich

[-- Attachment #2: Type: TEXT/PLAIN, Size: 2555 bytes --]

diff -rNu linux-2.4.1/include/linux/swap.h linux-2.4.1-paging-fix/include/linux/swap.h
--- linux-2.4.1/include/linux/swap.h	Tue Jan 30 02:24:56 2001
+++ linux-2.4.1-paging-fix/include/linux/swap.h	Tue Mar 27 10:43:22 2001
@@ -69,6 +69,7 @@
 FASTCALL(unsigned int nr_free_buffer_pages(void));
 extern int nr_active_pages;
 extern int nr_inactive_dirty_pages;
+extern int nr_swap_cache_pages;
 extern atomic_t nr_async_pages;
 extern struct address_space swapper_space;
 extern atomic_t page_cache_size;
diff -rNu linux-2.4.1/mm/mmap.c linux-2.4.1-paging-fix/mm/mmap.c
--- linux-2.4.1/mm/mmap.c	Mon Jan 29 11:10:41 2001
+++ linux-2.4.1-paging-fix/mm/mmap.c	Tue Mar 27 10:38:17 2001
@@ -63,6 +63,7 @@
 	free += atomic_read(&page_cache_size);
 	free += nr_free_pages();
 	free += nr_swap_pages;
+	free += nr_swap_cache_pages;
 	return free > pages;
 }
 
diff -rNu linux-2.4.1/mm/swap_state.c linux-2.4.1-paging-fix/mm/swap_state.c
--- linux-2.4.1/mm/swap_state.c	Fri Dec 29 18:04:27 2000
+++ linux-2.4.1-paging-fix/mm/swap_state.c	Tue Mar 27 10:41:04 2001
@@ -17,6 +17,8 @@
 
 #include <asm/pgtable.h>
 
+int nr_swap_cache_pages = 0;
+
 static int swap_writepage(struct page *page)
 {
 	rw_swap_page(WRITE, page, 0);
@@ -58,6 +60,7 @@
 #ifdef SWAP_CACHE_INFO
 	swap_cache_add_total++;
 #endif
+	nr_swap_cache_pages++;
 	if (!PageLocked(page))
 		BUG();
 	if (PageTestandSetSwapCache(page))
@@ -96,6 +99,7 @@
 #ifdef SWAP_CACHE_INFO
 	swap_cache_del_total++;
 #endif
+	nr_swap_cache_pages--;
 	remove_from_swap_cache(page);
 	swap_free(entry);
 }
diff -rNu linux-2.4.1/mm/vmscan.c linux-2.4.1-paging-fix/mm/vmscan.c
--- linux-2.4.1/mm/vmscan.c	Mon Jan 15 15:36:49 2001
+++ linux-2.4.1-paging-fix/mm/vmscan.c	Tue Mar 27 12:31:04 2001
@@ -466,6 +466,17 @@
 			continue;
 		}
 
+		if (PageSwapCache(page)) {
+			page_cache_get(page);
+			if(!is_page_shared(page)) {
+				delete_from_swap_cache_nolock(page);
+				UnlockPage(page);
+				page_cache_release(page);
+				continue;
+			}
+			page_cache_release(page);
+		}
+
 		/*
 		 * Dirty swap-cache page? Write it out if
 		 * last copy..
@@ -650,6 +661,17 @@
 			list_del(page_lru);
 			nr_active_pages--;
 			continue;
+		}
+
+		if (PageSwapCache(page)) {
+			page_cache_get(page);
+			if(!is_page_shared(page) && !TryLockPage(page)) {
+				delete_from_swap_cache_nolock(page);
+				UnlockPage(page);
+				page_cache_release(page);
+				continue;
+			}
+			page_cache_release(page);
 		}
 
 		/* Do aging on the pages. */

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2001-03-27 23:05 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-03-22 22:21 [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated) Richard Jerrell
2001-03-22 23:16 ` Rik van Riel
2001-03-23 16:32   ` Richard Jerrell
2001-03-23 11:21     ` Rik van Riel
2001-03-26 14:26 ` Stephen Tweedie
  -- strict thread matches above, loose matches on Subject: below --
2001-03-27 21:29 Richard Jerrell
2001-03-27 21:18 ` Rik van Riel
2001-03-27 23:10   ` Richard Jerrell
2001-03-27 22:57     ` Rik van Riel
2001-03-27 21:51 ` Linus Torvalds

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox