[PATCH] Re: 2.4.9-ac15 painfully sluggish

[PATCH] Re: 2.4.9-ac15 painfully sluggish

[Rik van Riel]

On Tue, 25 Sep 2001, Pau Aliagas wrote:

> The problem seems to be related in pages not moved to swap but
> being discarded somehow and reread later on.... just a guess.

I've made a small patch to 2.4.9-ac15 which should make
page_launder() smoother, make some (very minor) tweaks
to page aging and updates various comments in vmscan.c

It's below this email and at:

http://www.surriel.com/patches/2.4/2.4.9-ac15-age+launder

Since I failed to break 2.4.9-ac15 with this patch following
the instructions given to me by others, it would be nice to
know if the thing can still break on your machines.

Please test,

Rik
--
IA64: a worthy successor to the i860.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/




--- linux-2.4.9-ac15/mm/vmscan.c.orig	Mon Sep 24 17:30:48 2001
+++ linux-2.4.9-ac15/mm/vmscan.c	Tue Sep 25 13:33:16 2001
@@ -28,19 +28,12 @@

 static inline void age_page_up(struct page *page)
 {
-	unsigned long age = page->age;
-	age += PAGE_AGE_ADV;
-	if (age > PAGE_AGE_MAX)
-		age = PAGE_AGE_MAX;
-	page->age = age;
+	page->age = min((int) (page->age + PAGE_AGE_ADV), PAGE_AGE_MAX);
 }

 static inline void age_page_down(struct page *page)
 {
-	unsigned long age = page->age;
-	if (age > 0)
-		age -= PAGE_AGE_DECL;
-	page->age = age;
+	page->age -= min(PAGE_AGE_DECL, (int)page->age);
 }

 /*
@@ -108,6 +101,23 @@
 	pte_t pte;
 	swp_entry_t entry;

+	/* Don't look at this pte if it's been accessed recently. */
+	if (ptep_test_and_clear_young(page_table)) {
+		age_page_up(page);
+		return;
+	}
+
+	/*
+	 * If the page is on the active list, page aging is done in
+	 * refill_inactive_scan(), anonymous pages are aged here.
+	 * This is done so heavily shared pages (think libc.so)
+	 * don't get punished heavily while they are still in use.
+	 * The alternative would be to put anonymous pages on the
+	 * active list too, but that increases complexity (for now).
+	 */
+	if (!PageActive(page))
+		age_page_down(page);
+
 	/*
 	 * If we have plenty inactive pages on this
 	 * zone, skip it.
@@ -133,23 +143,6 @@
 	pte = ptep_get_and_clear(page_table);
 	flush_tlb_page(vma, address);

-	/* Don't look at this pte if it's been accessed recently. */
-	if (ptep_test_and_clear_young(page_table)) {
-		age_page_up(page);
-		return;
-	}
-
-	/*
-	 * If the page is on the active list, page aging is done in
-	 * refill_inactive_scan(), anonymous pages are aged here.
-	 * This is done so heavily shared pages (think libc.so)
-	 * don't get punished heavily while they are still in use.
-	 * The alternative would be to put anonymous pages on the
-	 * active list too, but that increases complexity (for now).
-	 */
-	if (!PageActive(page))
-		age_page_down(page);
-
 	/*
 	 * Is the page already in the swap cache? If so, then
 	 * we can just drop our reference to it without doing
@@ -447,6 +440,7 @@
 				page_count(page) > (1 + !!page->buffers)) {
 			del_page_from_inactive_clean_list(page);
 			add_page_to_active_list(page);
+			page->age = max((int)page->age, PAGE_AGE_START);
 			continue;
 		}

@@ -536,34 +530,56 @@
  * @gfp_mask: what operations we are allowed to do
  * @sync: are we allowed to do synchronous IO in emergencies ?
  *
- * When this function is called, we are most likely low on free +
- * inactive_clean pages. Since we want to refill those pages as
- * soon as possible, we'll make two loops over the inactive list,
- * one to move the already cleaned pages to the inactive_clean lists
- * and one to (often asynchronously) clean the dirty inactive pages.
+ * This function is called when we are low on free / inactive_clean
+ * pages, its purpose is to refill the free/clean list as efficiently
+ * as possible.
  *
- * In situations where kswapd cannot keep up, user processes will
- * end up calling this function. Since the user process needs to
- * have a page before it can continue with its allocation, we'll
- * do synchronous page flushing in that case.
+ * This means we do writes asynchronously as long as possible and will
+ * only sleep on IO when we don't have another option. Since writeouts
+ * cause disk seeks and make read IO slower, we skip writes alltogether
+ * when the amount of dirty pages is small.
  *
  * This code is heavily inspired by the FreeBSD source code. Thanks
  * go out to Matthew Dillon.
  */
-#define MAX_LAUNDER 		(4 * (1 << page_cluster))
-#define CAN_DO_FS		(gfp_mask & __GFP_FS)
-#define CAN_DO_IO		(gfp_mask & __GFP_IO)
+#define	CAN_DO_FS	((gfp_mask & __GFP_FS) && should_write)
+#define	WRITE_LOW_WATER		5
+#define	WRITE_HIGH_WATER	10
 int page_launder(int gfp_mask, int sync)
 {
-	int launder_loop, maxscan, cleaned_pages, maxlaunder;
+	int maxscan, cleaned_pages, failed_pages, total;
 	struct list_head * page_lru;
 	struct page * page;

-	launder_loop = 0;
-	maxlaunder = 0;
+	/*
+	 * This flag determines if we should do writeouts of dirty data
+	 * or not.  When more than WRITE_HIGH_WATER percentage of the
+	 * pages we process would need to be written out we set this flag
+	 * and will do writeout, the flag is cleared once we go below
+	 * WRITE_LOW_WATER.  Note that only pages we actually process
+	 * get counted, ie. pages where we make it beyond the TryLock.
+	 *
+	 * XXX: These flags still need tuning.
+	 */
+	static int should_write = 0;
+
 	cleaned_pages = 0;
+	failed_pages = 0;
+
+	/*
+	 * The gfp_mask tells try_to_free_buffers() below if it should
+	 * wait do IO or may be allowed to wait on IO synchronously.
+	 *
+	 * Note that syncronous IO only happens when a page has not been
+	 * written out yet when we see it for a second time, this is done
+	 * through magic in try_to_free_buffers().
+	 */
+	if (!should_write)
+		gfp_mask &= ~(__GFP_WAIT | __GFP_IO);
+	else if (!sync)
+		gfp_mask &= ~__GFP_WAIT;

-dirty_page_rescan:
+	/* The main launder loop. */
 	spin_lock(&pagemap_lru_lock);
 	maxscan = nr_inactive_dirty_pages;
 	while ((page_lru = inactive_dirty_list.prev) != &inactive_dirty_list &&
@@ -580,26 +596,36 @@
 		}

 		/*
-		 * If the page is or was in use, we move it to the active
-		 * list. Note that pages in use by processes can easily
-		 * end up here to be unmapped later, but we just don't
-		 * want them clogging up the inactive list.
+		 * The page is in active use or really unfreeable. Move to
+		 * the active list and adjust the page age if needed.
 		 */
-		if ((PageReferenced(page) || page->age > 0 ||
-				page_count(page) > (1 + !!page->buffers) ||
-				page_ramdisk(page)) && !PageLocked(page)) {
+		if (PageReferenced(page) || page->age || page_ramdisk(page)) {
 			del_page_from_inactive_dirty_list(page);
 			add_page_to_active_list(page);
+			page->age = max((int)page->age, PAGE_AGE_START);
 			continue;
 		}

 		/*
-		 * If we have plenty free pages on a zone:
+		 * The page is still in the page tables of some process,
+		 * move it to the active list but leave page age at 0;
+		 * either swap_out() will make it freeable soon or it is
+		 * mlock()ed...
 		 *
-		 * 1) we avoid a writeout for that page if its dirty.
-		 * 2) if its a buffercache page, and not a pagecache
-		 * one, we skip it since we cannot move it to the
-		 * inactive clean list --- we have to free it.
+		 * The !PageLocked() test is to protect us from ourselves,
+		 * see the code around the writepage() call.
+		 */
+		if ((page_count(page) > (1 + !!page->buffers)) &&
+						!PageLocked(page)) {
+			del_page_from_inactive_dirty_list(page);
+			add_page_to_active_list(page);
+			continue;
+		}
+
+		/*
+		 * If this zone has plenty of pages free, don't spend time
+		 * on cleaning it but only move clean pages out of the way
+		 * so we won't have to scan those again.
 		 */
 		if (zone_free_plenty(page->zone)) {
 			if (!page->mapping || page_dirty(page)) {
@@ -633,11 +659,12 @@
 			if (!writepage)
 				goto page_active;

-			/* First time through? Move it to the back of the list */
-			if (!launder_loop || !CAN_DO_FS) {
+			/* Can't do it? Move it to the back of the list. */
+			if (!CAN_DO_FS) {
 				list_del(page_lru);
 				list_add(page_lru, &inactive_dirty_list);
 				UnlockPage(page);
+				failed_pages++;
 				continue;
 			}

@@ -664,9 +691,7 @@
 		 * buffer pages
 		 */
 		if (page->buffers) {
-			unsigned int buffer_mask;
 			int clearedbuf;
-			int freed_page = 0;
 			/*
 			 * Since we might be doing disk IO, we have to
 			 * drop the spinlock and take an extra reference
@@ -676,16 +701,8 @@
 			page_cache_get(page);
 			spin_unlock(&pagemap_lru_lock);

-			/* Will we do (asynchronous) IO? */
-			if (launder_loop && maxlaunder == 0 && sync)
-				buffer_mask = gfp_mask;				/* Do as much as we can */
-			else if (launder_loop && maxlaunder-- > 0)
-				buffer_mask = gfp_mask & ~__GFP_WAIT;			/* Don't wait, async write-out */
-			else
-				buffer_mask = gfp_mask & ~(__GFP_WAIT | __GFP_IO);	/* Don't even start IO */
-
-			/* Try to free metadata underlying the page. */
-			clearedbuf = try_to_release_page(page, buffer_mask);
+			/* Try to free the page buffers. */
+			clearedbuf = try_to_release_page(page, gfp_mask);

 			/*
 			 * Re-take the spinlock. Note that we cannot
@@ -697,11 +714,11 @@
 			/* The buffers were not freed. */
 			if (!clearedbuf) {
 				add_page_to_inactive_dirty_list(page);
+				failed_pages++;

 			/* The page was only in the buffer cache. */
 			} else if (!page->mapping) {
 				atomic_dec(&buffermem_pages);
-				freed_page = 1;
 				cleaned_pages++;

 			/* The page has more users besides the cache and us. */
@@ -722,13 +739,6 @@
 			UnlockPage(page);
 			page_cache_release(page);

-			/*
-			 * If we're freeing buffer cache pages, stop when
-			 * we've got enough free memory.
-			 */
-			if (freed_page && !free_shortage())
-				break;
-
 			continue;
 		} else if (page->mapping && !PageDirty(page)) {
 			/*
@@ -750,33 +760,22 @@
 			 */
 			del_page_from_inactive_dirty_list(page);
 			add_page_to_active_list(page);
+			page->age = max((int)page->age, PAGE_AGE_START);
 			UnlockPage(page);
 		}
 	}
 	spin_unlock(&pagemap_lru_lock);

 	/*
-	 * If we don't have enough free pages, we loop back once
-	 * to queue the dirty pages for writeout. When we were called
-	 * by a user process (that /needs/ a free page) and we didn't
-	 * free anything yet, we wait synchronously on the writeout of
-	 * MAX_SYNC_LAUNDER pages.
-	 *
-	 * We also wake up bdflush, since bdflush should, under most
-	 * loads, flush out the dirty pages before we have to wait on
-	 * IO.
+	 * Set the should_write flag, for the next callers of page_launder.
+	 * If we go below the low watermark we stop the writeout of dirty
+	 * pages, writeout is started when we get above the high watermark.
 	 */
-	if (CAN_DO_IO && !launder_loop && free_shortage()) {
-		launder_loop = 1;
-		/* If we cleaned pages, never do synchronous IO. */
-		if (cleaned_pages)
-			sync = 0;
-		/* We only do a few "out of order" flushes. */
-		maxlaunder = MAX_LAUNDER;
-		/* Kflushd takes care of the rest. */
-		wakeup_bdflush(0);
-		goto dirty_page_rescan;
-	}
+	total = failed_pages + cleaned_pages;
+	if (should_write && failed_pages * 100 < WRITE_LOW_WATER * total)
+		should_write = 0;
+	else if (!should_write && failed_pages * 100 > WRITE_HIGH_WATER * total)
+		should_write = 1;

 	/* Return the number of pages moved to the inactive_clean list. */
 	return cleaned_pages;
@@ -998,27 +997,26 @@
 	return progress;
 }

-
-
+/*
+ * Worker function for kswapd and try_to_free_pages, we get
+ * called whenever there is a shortage of free/inactive_clean
+ * pages.
+ *
+ * This function will also move pages to the inactive list,
+ * if needed.
+ */
 static int do_try_to_free_pages(unsigned int gfp_mask, int user)
 {
 	int ret = 0;

 	/*
-	 * If we're low on free pages, move pages from the
-	 * inactive_dirty list to the inactive_clean list.
-	 *
-	 * Usually bdflush will have pre-cleaned the pages
-	 * before we get around to moving them to the other
-	 * list, so this is a relatively cheap operation.
+	 * Eat memory from filesystem page cache, buffer cache,
+	 * dentry, inode and filesystem quota caches.
 	 */
-
-	if (free_shortage()) {
-		ret += page_launder(gfp_mask, user);
-		shrink_dcache_memory(0, gfp_mask);
-		shrink_icache_memory(0, gfp_mask);
-		shrink_dqcache_memory(DEF_PRIORITY, gfp_mask);
-	}
+	ret += page_launder(gfp_mask, user);
+	shrink_dcache_memory(0, gfp_mask);
+	shrink_icache_memory(0, gfp_mask);
+	shrink_dqcache_memory(DEF_PRIORITY, gfp_mask);

 	/*
 	 * If needed, we move pages from the active list
@@ -1028,7 +1026,7 @@
 		ret += refill_inactive(gfp_mask);

 	/*
-	 * Reclaim unused slab cache if memory is low.
+	 * Reclaim unused slab cache memory.
 	 */
 	kmem_cache_reap(gfp_mask);

@@ -1080,7 +1078,7 @@
 		static long recalc = 0;

 		/* If needed, try to free some memory. */
-		if (inactive_shortage() || free_shortage())
+		if (free_shortage())
 			do_try_to_free_pages(GFP_KSWAPD, 0);

 		/* Once a second ... */
@@ -1090,8 +1088,6 @@
 			/* Do background page aging. */
 			refill_inactive_scan(DEF_PRIORITY);
 		}
-
-		run_task_queue(&tq_disk);

 		/*
 		 * We go to sleep if either the free page shortage

Re: [PATCH] Re: 2.4.9-ac15 painfully sluggish

[Jasper Spaans]

On Tue, Sep 25, 2001 at 04:32:13PM -0300, Rik van Riel wrote:

> > The problem seems to be related in pages not moved to swap but
> > being discarded somehow and reread later on.... just a guess.
> 
> I've made a small patch to 2.4.9-ac15 which should make
> page_launder() smoother, make some (very minor) tweaks
> to page aging and updates various comments in vmscan.c
> 
> It's below this email and at:
[snip]

With this -painfully applied- patch, all seems a lot better. However, it
still seems more sluggish than 2.4.9-ac12.

Haven't bothered testing -ac13 and -ac14.

Swapping still seems to be a problem though, as this kernel happily claims
several tens of MBs of swap, and then, out of the blue, starts writing pages
out in huge blocks.

The vmstat info just disappeared from my screen, while stressing the
vm-system by doing a large parallel build, however, it showed no paging
happening during long times (20-30 secs) and then suddenly writing 30 MB in
one go.

Doesn't seem very smooth to me, where can I get my refund? :)

(if you'd like more details, please ask, I can do some testing)

Regards,
-- 
  Q_.           Jasper Spaans <jasper@spaans.ds9a.nl>
 `~\            http://jsp.ds9a.nl/
Mr /\           Tel/Fax: +31-84-8749842
Zap             Move '.sig' for great justice!

Re: [PATCH] Re: 2.4.9-ac15 painfully sluggish

[Rik van Riel]

On Tue, 25 Sep 2001, Jasper Spaans wrote:

> (if you'd like more details, please ask, I can do some testing)

Some 'vmstat -a' output would be helpful, as well as a
screen of top.

Rik
--
IA64: a worthy successor to the i860.

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: [PATCH] Re: 2.4.9-ac15 painfully sluggish

[Pau Aliagas]

On Tue, 25 Sep 2001, Rik van Riel wrote:

> On Tue, 25 Sep 2001, Pau Aliagas wrote:
>
> I've made a small patch to 2.4.9-ac15 which should make
> page_launder() smoother, make some (very minor) tweaks
> to page aging and updates various comments in vmscan.c

Ok, things improve vastly and the system is usable again. I cannot
"notice" any difference with ac10 in terms of speed.

I attach the top and vmstat outputs while running updatedb (reads all
the files in the filesystems) and starting evolution for the first time
(touches all the mail folders, that's hundreths of files). It starts
smoothly in seconds.

  9:30am  up 52 min,  5 users,  load average: 2,83, 2,35, 1,87
125 processes: 121 sleeping, 4 running, 0 zombie, 0 stopped
CPU states: 16,2% user,  7,9% system, 75,8% nice,  0,0% idle
Mem:   127072K av,  123336K used,    3736K free,    2360K shrd,    7988K buff
Swap:  401536K av,   54092K used,  347444K free                   33952K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1008 setiatho  20  19 15348  14M   708 R N  76,2 11,4  38:28 setiathome
 1045 root       9   0 29740  12M  4076 S     7,3  9,6   9:05 X
 2238 pau        9   0  8876 8876  6764 D     4,1  6,9   0:00 evolution-mail
 1278 pau        9   0  4276 3776  3444 S     2,5  2,9   0:45 deskguide_apple
 2192 pau        9   0 16272  15M  6064 S     1,9 12,8   0:01 evolution
 1176 pau        9   0  1784 1456  1352 R     1,5  1,1   0:01 xscreensaver
    4 root       9   0     0    0     0 SW    0,9  0,0   0:02 kswapd
 2189 pau       13   0  1096 1096   840 R     0,9  0,8   0:00 top
 2258 pau        9   0  6024 6024  4632 S     0,9  4,7   0:00 evolution-pine-
 2198 pau        9   0  5616 5616  4360 D     0,7  4,4   0:00 wombat
 1127 pau        9   0  3424 3208  2032 S     0,3  2,5   0:03 sawfish
 1188 pau        9   0  5428 4972  4172 S     0,3  3,9   0:02 panel
 2265 pau        9   0  5372 5372  4216 S     0,3  4,2   0:00 evolution-gnome
  944 xfs        9   0  4748 2160  1768 D     0,1  1,6   0:01 xfs
 1198 pau        9   0  5232 3992  3472 S     0,1  3,1   0:02 gnome-terminal
 1944 root      19  19   716  676   496 R N   0,1  0,5   0:01 updatedb
 2093 pau        9   0   524  496   444 S     0,1  0,3   0:00 vmstat

   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 4  1  0  57552   3620  14280  42892   9  18    78    28  124   881  95   3   2
 1 11  0  54756   8220  14452  40896 386 115   614   163  244   560  96   4   0
 3  0  0  54660   7208  14720  41432 234   0   394     0  180   358  97   3   0
 5  0  0  54660   4952  15196  42508  74   0   381     0  162   295  98   2   0
 3  2  0  53856   5680  13244  42476 197   2   428    14  205   443  95   5   0
 2  4  0  53856   3668  13668  43212 170   0   395     6  180   399  97   3   0
 1  3  0  54004   5852  10324  42724 114   0   368     1  176   841  93   6   1
 4  0  0  54000   2800  10640  41908  19   0   314     2  151   764  95   5   0
 3  0  0  54024   6788   7568  39048   1   0   350     6  172   497  95   5   0
 1  2  0  54024   4656   7780  40192  78   0   347    11  163   524  96   4   0
 4  0  0  53972   2936   7944  38844 230   0   420     4  193  1370  94   6   0
 3  0  0  53972  12944   8420  39136  63   0   285    11  198  1262  96   4   0
 4  0  0  53972  11816   8836  39644  19   0   242    14  164   426  97   3   0
 4  0  0  53972  10532   9216  40252  31   0   222    17  215   834  96   4   0
 3  1  0  53972   8628   9504  40944  42   0   235     4  212   514  96   4   0
 2  1  0  53972   4040   9732  41636   0   0   173     2  210   798  95   5   0
 4  2  0  54160   3096   7188  40800  32   0   207    32  134  1502  87  13   0
 3  0  0  54332   3732   6412  35452  10   0   242    16  178   773  96   4   0
 4  0  0  54332   2800   7060  33908   0   0   232    16  204   506  96   4   0
 4  0  0  54072   4616   7096  34748   0 572   211   679  207   436  97   3   0
 3  2  0  54024   2800   7280  35364   0  12   244    18  216   726  97   3   0
 7  0  0  54020   3104   7644  34116  41   0   229     0  175   954  93   7   0
 3  1  0  54000   3744   7888  33852  62   0   374     0  193   722  97   3   0
 2  4  0  54092   4952   7988  33856   8   0   118   180  170  2934  91   9   0
 4  1  0  54036   2992   8024  34312  38   0   102   444  237  1684  92   8   0
 2  0  0  54036   3580   8216  35092   0   0   208     0  173   356  97   3   0
 3  0  0  55016   3820   8444  34912   3  67   293   136  165   279  90   2   8
 3  0  0  55016   2800   8724  34820   0   0   202    15  177   385  98   2   0
 4  0  0  55016   2948   9008  34704   0   0   258    14  175   372  98   2   0


Pau

Re: [PATCH] Re: 2.4.9-ac15 painfully sluggish

[Kent Borg]

On Tue, Sep 25, 2001 at 04:32:13PM -0300, Rik van Riel wrote:
> I've made a small patch to 2.4.9-ac15 which should make
> page_launder() smoother, make some (very minor) tweaks
> to page aging and updates various comments in vmscan.c

Works for me.  I have the premption patch turned on.

On a 192 MB PIII laptop running at 500 MHz I have two X sessions
running, and have opened a zillion application windows on each,
including over a dozen Netscape windows, some Mozilla's, a couple
emacs's, a kernel compile, Staroffice.  About every app I can
immediately think of.  I haven't tried malloc-ing a ton of memory, but
this contrived real-world test works.

Swap is at 238 MB.  Lower than I would have expected, but that doesn't
mean I know anything.

Switching between X sessions just took near 10-seconds going, and only
about 5-seconds coming back.  Switching in Staroffice is painful, but
generally the responsiveness feels quite nice.

I like it.  Thanks,

-kb, the Kent who will be staying with 2.4.9-ac15, plus preemption
patch, plus this patch--once he figures out how to close all those
windows.

Re: [PATCH] Re: 2.4.9-ac15 painfully sluggish

[Thomas Hood]

I know next to nothing about these VM issues, but here's
another data point:

2.4.9-ac15 was painfully sluggish on my ThinkPad 600,
Pentium II, 120 MB RAM system just running galeon
or compiling a kernel.  The disk would begin thrashing
and continue doing so for many minutes.  Swap usage was
reported as zero the whole time.

I applied the "2.4.9-ac15-age+launder" patch and things
improved dramatically.

--

Thomas

Re: [PATCH] Re: 2.4.9-ac15 painfully sluggish

[Alan Cox]

> or compiling a kernel.  The disk would begin thrashing
> and continue doing so for many minutes.  Swap usage was
> reported as zero the whole time.

Ac15 had a merge error