Re: [PATCH] [2.4.17/18pre] VM and swap - it's really unusable

Re: [PATCH] [2.4.17/18pre] VM and swap - it's really unusable

[M.H.VanLeeuwen]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

Andreas,

Glad you liked oom2 patch ;)

I split of the patch into 2 pieces, mostly because the OOM killer tamer isn't
really needed anymore with the characteristics of the vmscan/cache recovery
changes.  Both are a little different then before.

a. bug fixed oom killer that looked at whether or not cache was shrinking.
   A greater or equal check should have been a greater then check only...unless
   you were severely stressing your system you probably wouldn't have hit this
   and because vmscan/cache recovery is working quite well.

b. removed nr_swap_pages from the check before deciding to goto swap_out.  it seems
   that we really do need to go to swap_out even for systems w/o any swap to clean
   up various resources before some cache can be recovered.  Unless you run out of
   swap space or have no swap device you probably didn't hit this problem either.

I'm a little concerned about the amount of pages we are potentially throwing between
the active and inactive (refill_inactive) and back again once max_mapped is hit, but
a few experiments with limiting page movement between lists just seemed to make
near OOM performance much worse (lengthly system pauses & mouse freezes).

Anyone else have any comments on the patch(es)?

Do they make any since, if so, should either/both patches or pieces therof be
pushed to Marcello?

Martin
--------------------------------------------------------------------------------------
OOM tamer patch:

a. if cache continues to shrink, we're not OOM, just reset OOM variables and exit
b. instead of waiting 1 second, wait variable time based on Mb of cache, thus the
   larger the cache the longer we wait to start killing processes.  eg 10 megs of
   cache causes OOM killer to wait 10 seconds before starting "c" below.
c. instead of fixed 10 occurrances after the N second wait above, wait 10 * Mb cache.

vmscan patch:

a. instead of calling swap_out as soon as max_mapped is reached, continue to try
   to free pages.  this reduces the number of times we hit try_to_free_pages() and
   swap_out().
b. once max_mapped count is reached move any Referenced pages to the active list, until
   enough pages have been freed or there are no more pages that can be freed.
c. only call swap_out() if both max_mapped is reached and we fail to free enough pages.

[-- Attachment #2: oom.patch.2.4.17 --]
[-- Type: application/octet-stream, Size: 1285 bytes --]

--- ./mm/oom_kill.c	Mon Nov  5 19:45:10 2001
+++ /usr/src/linux/./mm/oom_kill.c	Sun Dec 30 21:35:19 2001
@@ -198,7 +198,7 @@
  */
 void out_of_memory(void)
 {
-	static unsigned long first, last, count;
+	static unsigned long first, last, count, mega;
 	unsigned long now, since;
 
 	/*
@@ -220,19 +220,30 @@
 		goto reset;
 
 	/*
-	 * If we haven't tried for at least one second,
+	 * If cache is still shrinking, we're not oom.
+	 */
+	if (mega > pages_to_mb(atomic_read(&page_cache_size))) {
+		goto reset;
+	}
+
+	/*
+	 * If we haven't tried for at least mega*second(s),
 	 * we're not really oom.
 	 */
 	since = now - first;
-	if (since < HZ)
+	if (since < mega * HZ) {
+		printk(KERN_DEBUG "out_of_memory: cache size %d Mb, since = %lu.%02lu\n",mega, since/HZ, since%HZ);
 		return;
+	}
 
 	/*
-	 * If we have gotten only a few failures,
+	 * If we haven't gotten mega failures,
 	 * we're not really oom. 
 	 */
-	if (++count < 10)
+	if (++count < mega * 10) {
+		printk(KERN_DEBUG "out_of_memory: cache size %d Mb, since = %lu.%02lu, count %d\n",mega, since/HZ, since%HZ, count);
 		return;
+	}
 
 	/*
 	 * Ok, really out of memory. Kill something.
@@ -240,6 +251,7 @@
 	oom_kill();
 
 reset:
+	mega = pages_to_mb(atomic_read(&page_cache_size));
 	first = now;
 	count = 0;
 }

[-- Attachment #3: vmscan.patch.2.4.17 --]
[-- Type: application/octet-stream, Size: 1929 bytes --]

--- ./mm/swap.c	Sat Nov 24 23:59:28 2001
+++ /usr/src/linux/./mm/swap.c	Sun Dec 30 14:26:45 2001
@@ -36,7 +36,7 @@
 /*
  * Move an inactive page to the active list.
  */
-static inline void activate_page_nolock(struct page * page)
+void activate_page_nolock(struct page * page)
 {
 	if (PageLRU(page) && !PageActive(page)) {
 		del_page_from_inactive_list(page);
--- ./mm/vmscan.c	Sat Dec 22 09:35:54 2001
+++ /usr/src/linux/./mm/vmscan.c	Sun Dec 30 23:40:10 2001
@@ -394,9 +394,9 @@
 		if (PageDirty(page) && is_page_cache_freeable(page) && page->mapping) {
 			/*
 			 * It is not critical here to write it only if
-			 * the page is unmapped beause any direct writer
+			 * the page is unmapped because any direct writer
 			 * like O_DIRECT would set the PG_dirty bitflag
-			 * on the phisical page after having successfully
+			 * on the physical page after having successfully
 			 * pinned it and after the I/O to the page is finished,
 			 * so the direct writes to the page cannot get lost.
 			 */
@@ -480,11 +480,12 @@
 
 			/*
 			 * Alert! We've found too many mapped pages on the
-			 * inactive list, so we start swapping out now!
+			 * inactive list.
+			 * Move referenced pages to the active list.
 			 */
-			spin_unlock(&pagemap_lru_lock);
-			swap_out(priority, gfp_mask, classzone);
-			return nr_pages;
+			if (PageReferenced(page))
+				activate_page_nolock(page);
+			continue;
 		}
 
 		/*
@@ -521,6 +522,9 @@
 	}
 	spin_unlock(&pagemap_lru_lock);
 
+	if (max_mapped <= 0 && nr_pages > 0)
+		swap_out(priority, gfp_mask, classzone);
+
 	return nr_pages;
 }
 
--- ./include/linux/swap.h	Sat Nov 24 23:59:24 2001
+++ /usr/src/linux/./include/linux/swap.h	Sun Dec 30 15:01:21 2001
@@ -106,6 +106,7 @@
 extern void FASTCALL(lru_cache_del(struct page *));
 
 extern void FASTCALL(activate_page(struct page *));
+extern void FASTCALL(activate_page_nolock(struct page *));
 
 extern void swap_setup(void);
 

Re: [PATCH] [2.4.17/18pre] VM and swap - it's really unusable

[Stephan von Krawczynski]

On Mon, 31 Dec 2001 11:14:04 -0600
"M.H.VanLeeuwen" <vanl@megsinet.net> wrote:

> [...]
> vmscan patch:
> 
> a. instead of calling swap_out as soon as max_mapped is reached, continue to
try>    to free pages.  this reduces the number of times we hit
try_to_free_pages() and>    swap_out().

I experimented with this some time ago, but found out it hit performance and
(to my own surprise) did not do any good at all. Have you tried this
stand-alone/on top of the rest to view its results?

Regards,
Stephan

Re: [PATCH] [2.4.17/18pre] VM and swap - it's really unusable

[M.H.VanLeeuwen]

Stephan von Krawczynski wrote:
> 
> On Mon, 31 Dec 2001 11:14:04 -0600
> "M.H.VanLeeuwen" <vanl@megsinet.net> wrote:
> 
> > [...]
> > vmscan patch:
> >
> > a. instead of calling swap_out as soon as max_mapped is reached, continue to
> try>    to free pages.  this reduces the number of times we hit
> try_to_free_pages() and>    swap_out().
> 
> I experimented with this some time ago, but found out it hit performance and
> (to my own surprise) did not do any good at all. Have you tried this
> stand-alone/on top of the rest to view its results?


No benchmarks specifically to show changes yet.  Hmmm, I found quite the opposite from
an interactive feeling on SMP and I was happy not to have a kernel killing processes
out of the blue when it started hitting the upper limits of VM.  Especially when there
was still plenty of cache to be evicted (the original reason for the OOM tamer).

Yes, your performance loss may be from having less cache overall since the kernel is
swapping out less. OTOH we tend to not hit shrink_[di]cache_memory much less with this
change.

I'll try to time some kernel compiles with the vmscan patch...
compile times and amount of swap used afterwards, from a cold start and subsequent
compile, etc.

Andreas Hartmann generated a comparison of many kernel VM's including Andrea's and Rick's
and the last AC patch.  I'll send it to you separately since it is rather large and
everyone Cc'd has already seen it.

As was pointed out earlier it sure will be nice once we have some cache stats...

Willing to give this one a try to see if it is still a performance hit for you? 
VM has probably change since "some time ago". ;)


Martin

Re: [2.4.17/18pre] VM and swap - it's really unusable

[M.H.VanLeeuwen]

[-- Attachment #1: Type: text/plain, Size: 4338 bytes --]

Stephan von Krawczynski wrote:
> 
> On Mon, 31 Dec 2001 11:14:04 -0600
> "M.H.VanLeeuwen" <vanl@megsinet.net> wrote:
> 
> > [...]
> > vmscan patch:
> >
> > a. instead of calling swap_out as soon as max_mapped is reached, continue to
> try>    to free pages.  this reduces the number of times we hit
> try_to_free_pages() and>    swap_out().
> 
> I experimented with this some time ago, but found out it hit performance and
> (to my own surprise) did not do any good at all. Have you tried this
> stand-alone/on top of the rest to view its results?
> 
> Regards,
> Stephan

Stephan,

Here is what I've run thus far.  I'll add nfs file copy into the mix also...

System: SMP 466 Celeron 192M RAM, running KDE, xosview, and other minor apps.

Each run after clean & cache builds has 1 more setiathome client running upto a
max if 8 seti clients.  No, this isn't my normal way of running setiathome, but
each instance uses a nice chunk of memory.

Note: this is a single run for each of the columns using "make -j2 bzImage" each time.

I will try to run aa and rmap this evening and/or tomorrow.

Martin

----------------------------------------------------------------------------

                STOCK KERNEL    MH KERNEL       STOCK + SWAP    MH + SWAP
                (no swap)       (no swap)

CLEAN
BUILD   real    7m19.428s       7m19.546s       7m26.852s       7m26.256s
        user    12m53.640s      12m50.550s      12m53.740s      12m47.110s
        sys     0m47.890s       0m54.960s       0m58.810s       1m1.090s
                                                1.1M swp        0M swp

CACHE
BUILD   real    7m3.823s        7m3.520s        7m4.040s        7m4.266s
        user    12m47.710s      12m49.110s      12m47.640s      12m40.120s
        sys     0m46.660s       0m46.270s       0m47.480s       0m51.440s
                                                1.1M swp        0M swp

SETI 1
        real    9m51.652s       9m50.601s       9m53.153s       9m53.668s
        user    13m5.250s       13m4.420s       13m5.040s       13m4.470s
        sys     0m49.020s       0m50.460s       0m51.190s       0m50.580s
                                                1.1M swp        0M swp

SETI 2
        real    13m9.730s       13m7.719s       13m4.279s       13m4.768s
        user    13m16.810s      13m15.150s      13m15.950s      13m13.400s
        sys     0m50.880s       0m50.460s       0m50.930s       0m52.520s
                                                5.8M swp        1.9M swp

SETI 3
        real    15m49.331s      15m41.264s      15m40.828s      15m45.551s
        user    13m22.150s      13m21.560s      13m14.390s      13m20.790s
        sys     0m49.250s       0m49.910s       0m49.850s       0m50.910s
                                                16.2M swp       3.1M swp

SETI 4
        real    OOM KILLED      19m8.435s       19m5.584s       19m3.618s
        user    kdeinit         13m24.570s      13m24.000s      13m22.520s
        sys                     0m51.430s       0m50.320s       0m51.390s
                                                18.7M swp       8.3M swp
SETI 5
        real    NA              21m35.515s      21m48.543s      22m0.240s
        user                    13m9.680s       13m22.030s      13m28.820s
        sys                     0m49.910s       0m50.850s       0m52.270s
                                                31.7M swp       11.3M swp

SETI 6
        real    NA              24m37.167s      25m5.244s       25m13.429s
        user                    13m7.650s       13m26.590s      13m32.640s
        sys                     0m51.390s       0m51.260s       0m52.790s
                                                35.3M swp       17.1M swp

SETI 7
        real    NA              28m40.446s      28m3.612s       28m12.981s
        user                    13m16.460s      13m26.130s      13m31.520s
        sys                     0m57.940s       0m52.510s       0m53.570s
                                                38.8M swp       25.4M swp

SETI 8
        real    NA              29m31.743s      31m16.275s      32m29.534s
        user                    13m37.610s      13m27.740s      13m33.630s
        sys                     1m4.450s        0m52.100s       0m54.140s
                                                41.5M swp       49.7M swp (hmmm?)

[-- Attachment #2: vmscan.patch.2.4.17.c --]
[-- Type: application/octet-stream, Size: 1275 bytes --]

--- linux.virgin/mm/vmscan.c	Mon Dec 31 12:46:25 2001
+++ linux/mm/vmscan.c	Thu Jan  3 19:43:02 2002
@@ -394,9 +394,9 @@
 		if (PageDirty(page) && is_page_cache_freeable(page) && page->mapping) {
 			/*
 			 * It is not critical here to write it only if
-			 * the page is unmapped beause any direct writer
+			 * the page is unmapped because any direct writer
 			 * like O_DIRECT would set the PG_dirty bitflag
-			 * on the phisical page after having successfully
+			 * on the physical page after having successfully
 			 * pinned it and after the I/O to the page is finished,
 			 * so the direct writes to the page cannot get lost.
 			 */
@@ -480,11 +480,14 @@
 
 			/*
 			 * Alert! We've found too many mapped pages on the
-			 * inactive list, so we start swapping out now!
+			 * inactive list.
+			 * Move referenced pages to the active list.
 			 */
-			spin_unlock(&pagemap_lru_lock);
-			swap_out(priority, gfp_mask, classzone);
-			return nr_pages;
+			if (PageReferenced(page)) {
+				del_page_from_inactive_list(page);
+				add_page_to_active_list(page);
+			}
+			continue;
 		}
 
 		/*
@@ -521,6 +524,9 @@
 	}
 	spin_unlock(&pagemap_lru_lock);
 
+	if (max_mapped <= 0 && nr_pages > 0)
+		swap_out(priority, gfp_mask, classzone);
+
 	return nr_pages;
 }
 

Re: [2.4.17/18pre] VM and swap - it's really unusable

[Stephan von Krawczynski]

On Thu, 03 Jan 2002 20:14:42 -0600
"M.H.VanLeeuwen" <vanl@megsinet.net> wrote:
 
> Stephan,
> 
> Here is what I've run thus far.  I'll add nfs file copy into the mix also...

Ah, Martin, thanks for sending the patch. I think I saw the voodoo in your
patch. When I did that last time I did _not_ do this:

+                       if (PageReferenced(page)) {
+                               del_page_from_inactive_list(page);
+                               add_page_to_active_list(page);
+                       } 
+                       continue;

This may shorten your inactive list through consecutive runs.

And there is another difference here:

+       if (max_mapped <= 0 && nr_pages > 0)
+               swap_out(priority, gfp_mask, classzone);
+

It sounds reasonable _not_ to swap in case of success (nr_pages == 0).
To me this looks pretty interesting. Is something like this already in -aa?
This patch may be worth applying in 2.4. It is small and looks like the right
thing to do.

Regards,
Stephan

Re: [2.4.17/18pre] VM and swap - it's really unusable

[Andrea Arcangeli]

On Thu, Jan 03, 2002 at 08:14:42PM -0600, M.H.VanLeeuwen wrote:
> Stephan von Krawczynski wrote:
> > 
> > On Mon, 31 Dec 2001 11:14:04 -0600
> > "M.H.VanLeeuwen" <vanl@megsinet.net> wrote:
> > 
> > > [...]
> > > vmscan patch:
> > >
> > > a. instead of calling swap_out as soon as max_mapped is reached, continue to
> > try>    to free pages.  this reduces the number of times we hit
> > try_to_free_pages() and>    swap_out().
> > 
> > I experimented with this some time ago, but found out it hit performance and
> > (to my own surprise) did not do any good at all. Have you tried this
> > stand-alone/on top of the rest to view its results?
> > 
> > Regards,
> > Stephan
> 
> Stephan,
> 
> Here is what I've run thus far.  I'll add nfs file copy into the mix also...
> 
> System: SMP 466 Celeron 192M RAM, running KDE, xosview, and other minor apps.
> 
> Each run after clean & cache builds has 1 more setiathome client running upto a
> max if 8 seti clients.  No, this isn't my normal way of running setiathome, but
> each instance uses a nice chunk of memory.
> 
> Note: this is a single run for each of the columns using "make -j2 bzImage" each time.
> 
> I will try to run aa and rmap this evening and/or tomorrow.

The design changes Linus did was explicitly to left the mapped pages
into the inactive list so we learn when we should trigger swapout. Also
it is nicer to swapout over the shrinking. rc2aa2 should work just fine.
Have a look at how such logic is implemented there. (btw, I will shortly
sync with 18pre, 2.2 and 2.5)

Andrea

Re: [2.4.17/18pre] VM and swap - it's really unusable

[Andrea Arcangeli]

On Fri, Jan 04, 2002 at 01:33:21PM +0100, Stephan von Krawczynski wrote:
> On Thu, 03 Jan 2002 20:14:42 -0600
> "M.H.VanLeeuwen" <vanl@megsinet.net> wrote:
>  
> > Stephan,
> > 
> > Here is what I've run thus far.  I'll add nfs file copy into the mix also...
> 
> Ah, Martin, thanks for sending the patch. I think I saw the voodoo in your
> patch. When I did that last time I did _not_ do this:
> 
> +                       if (PageReferenced(page)) {
> +                               del_page_from_inactive_list(page);
> +                               add_page_to_active_list(page);
> +                       } 
> +                       continue;
> 
> This may shorten your inactive list through consecutive runs.
> 
> And there is another difference here:
> 
> +       if (max_mapped <= 0 && nr_pages > 0)
> +               swap_out(priority, gfp_mask, classzone);
> +
> 
> It sounds reasonable _not_ to swap in case of success (nr_pages == 0).
> To me this looks pretty interesting. Is something like this already in -aa?
> This patch may be worth applying in 2.4. It is small and looks like the right
> thing to do.

-aa swapout as soon as max_mapped hits zero. So it basically does it
internally (i.e. way more times) and so it will most certainly be able
to sustain an higher swap transfer rate. You can check with the mtest01
-w test from ltp.

Andrea

Re: [2.4.17/18pre] VM and swap - it's really unusable

[Stephan von Krawczynski]

On Fri, 4 Jan 2002 15:14:38 +0100
Andrea Arcangeli <andrea@suse.de> wrote:

> On Fri, Jan 04, 2002 at 01:33:21PM +0100, Stephan von Krawczynski wrote:
> > On Thu, 03 Jan 2002 20:14:42 -0600
> > "M.H.VanLeeuwen" <vanl@megsinet.net> wrote:
> > 
> > And there is another difference here:
> > 
> > +       if (max_mapped <= 0 && nr_pages > 0)
> > +               swap_out(priority, gfp_mask, classzone);
> > +
> > 
> > It sounds reasonable _not_ to swap in case of success (nr_pages == 0).
> > To me this looks pretty interesting. Is something like this already in -aa?
> > This patch may be worth applying in 2.4. It is small and looks like the
right> > thing to do.
> 
> -aa swapout as soon as max_mapped hits zero. So it basically does it
> internally (i.e. way more times) and so it will most certainly be able
> to sustain an higher swap transfer rate. You can check with the mtest01
> -w test from ltp.

Hm, but do you think this is really good in overall performance, especially the
frequent cases where no swap should be needed _at all_ to do a successful
shrinking? And - as can be viewed in Martins tests - if you have no swap at
all, you seem to trigger OOM earlier through the short path exit in shrink,
which is a obvious nono. I would state it wrong to fix the oom-killer for this
case, because it should not be reached at all.

?

Regards,
Stephan

Re: [2.4.17/18pre] VM and swap - it's really unusable

[Andrea Arcangeli]

On Fri, Jan 04, 2002 at 03:24:09PM +0100, Stephan von Krawczynski wrote:
> On Fri, 4 Jan 2002 15:14:38 +0100
> Andrea Arcangeli <andrea@suse.de> wrote:
> 
> > On Fri, Jan 04, 2002 at 01:33:21PM +0100, Stephan von Krawczynski wrote:
> > > On Thu, 03 Jan 2002 20:14:42 -0600
> > > "M.H.VanLeeuwen" <vanl@megsinet.net> wrote:
> > > 
> > > And there is another difference here:
> > > 
> > > +       if (max_mapped <= 0 && nr_pages > 0)
> > > +               swap_out(priority, gfp_mask, classzone);
> > > +
> > > 
> > > It sounds reasonable _not_ to swap in case of success (nr_pages == 0).
> > > To me this looks pretty interesting. Is something like this already in -aa?
> > > This patch may be worth applying in 2.4. It is small and looks like the
> right> > thing to do.
> > 
> > -aa swapout as soon as max_mapped hits zero. So it basically does it
> > internally (i.e. way more times) and so it will most certainly be able
> > to sustain an higher swap transfer rate. You can check with the mtest01
> > -w test from ltp.
> 
> Hm, but do you think this is really good in overall performance, especially the
> frequent cases where no swap should be needed _at all_ to do a successful
> shrinking? And - as can be viewed in Martins tests - if you have no swap at

the common case is that max_mapped doesn't reach zero, so either ways
(mainline or -aa) it's the same (i.e. no special exit path).

> all, you seem to trigger OOM earlier through the short path exit in shrink,
> which is a obvious nono. I would state it wrong to fix the oom-killer for this
> case, because it should not be reached at all.

Correct. Incidentally swap or no swap doesn't make any difference on the
exit-path of shrink_cache in -aa (furthmore if swap is full or if everything is
unfreeable I stop wasting an huge amount of time on the swap_out path at the
first failure, this allows graceful oom handling or it would nearly deadlock
there trying tp swap unfreeable stuff at every max_mapped reached). In -aa
max_mapped doesn't influcence in any way the exit path of shrink_cache.
max_mapped only controls the swapout-frequency. See:

		if (!page->mapping || page_count(page) > 1) {
			spin_unlock(&pagecache_lock);
			UnlockPage(page);
		page_mapped:
			if (--max_mapped < 0) {
				spin_unlock(&pagemap_lru_lock);

				shrink_dcache_memory(vm_scan_ratio, gfp_mask);
				shrink_icache_memory(vm_scan_ratio, gfp_mask);
#ifdef CONFIG_QUOTA
				shrink_dqcache_memory(vm_scan_ratio, gfp_mask);
#endif

				if (!*failed_swapout)
					*failed_swapout = !swap_out(classzone);

				max_mapped = orig_max_mapped;
				spin_lock(&pagemap_lru_lock);
			}
			continue;
			
		}

So it should work just fine as far I can tell.

Andrea

Re: [2.4.17/18pre] VM and swap - it's really unusable

[M.H.VanLeeuwen]

Andrea Arcangeli wrote:
> 
> On Fri, Jan 04, 2002 at 03:24:09PM +0100, Stephan von Krawczynski wrote:
> > On Fri, 4 Jan 2002 15:14:38 +0100
> > Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > > On Fri, Jan 04, 2002 at 01:33:21PM +0100, Stephan von Krawczynski wrote:
> > > > On Thu, 03 Jan 2002 20:14:42 -0600
> > > > "M.H.VanLeeuwen" <vanl@megsinet.net> wrote:
> > > >
> > > > And there is another difference here:
> > > >
> > > > +       if (max_mapped <= 0 && nr_pages > 0)
> > > > +               swap_out(priority, gfp_mask, classzone);
> > > > +
> > > >
> > > > It sounds reasonable _not_ to swap in case of success (nr_pages == 0).
> > > > To me this looks pretty interesting. Is something like this already in -aa?
> > > > This patch may be worth applying in 2.4. It is small and looks like the
> > right> > thing to do.
> > >
> > > -aa swapout as soon as max_mapped hits zero. So it basically does it
> > > internally (i.e. way more times) and so it will most certainly be able
> > > to sustain an higher swap transfer rate. You can check with the mtest01
> > > -w test from ltp.
> >
> > Hm, but do you think this is really good in overall performance, especially the
> > frequent cases where no swap should be needed _at all_ to do a successful
> > shrinking? And - as can be viewed in Martins tests - if you have no swap at
> 
> the common case is that max_mapped doesn't reach zero, so either ways
> (mainline or -aa) it's the same (i.e. no special exit path).
> 
> > all, you seem to trigger OOM earlier through the short path exit in shrink,
> > which is a obvious nono. I would state it wrong to fix the oom-killer for this
> > case, because it should not be reached at all.
> 
> Correct. Incidentally swap or no swap doesn't make any difference on the
> exit-path of shrink_cache in -aa (furthmore if swap is full or if everything is
> unfreeable I stop wasting an huge amount of time on the swap_out path at the
> first failure, this allows graceful oom handling or it would nearly deadlock
> there trying tp swap unfreeable stuff at every max_mapped reached). In -aa
> max_mapped doesn't influcence in any way the exit path of shrink_cache.
> max_mapped only controls the swapout-frequency. See:
> 
>                 if (!page->mapping || page_count(page) > 1) {
>                         spin_unlock(&pagecache_lock);
>                         UnlockPage(page);
>                 page_mapped:
>                         if (--max_mapped < 0) {
>                                 spin_unlock(&pagemap_lru_lock);
> 
>                                 shrink_dcache_memory(vm_scan_ratio, gfp_mask);
>                                 shrink_icache_memory(vm_scan_ratio, gfp_mask);
> #ifdef CONFIG_QUOTA
>                                 shrink_dqcache_memory(vm_scan_ratio, gfp_mask);
> #endif
> 
>                                 if (!*failed_swapout)
>                                         *failed_swapout = !swap_out(classzone);
> 
>                                 max_mapped = orig_max_mapped;
>                                 spin_lock(&pagemap_lru_lock);
>                         }
>                         continue;
> 
>                 }
> 
> So it should work just fine as far I can tell.
> 
> Andrea

OK, here is RMAP 10c and RC2AA2 as well with the same load as previously used.

System: SMP 466 Celeron 192M RAM, ATA-66 40G IDE

Each run after clean & cache builds has 1 more setiathome client running upto a
max if 8 seti clients.  No, this isn't my normal way of running setiathome, but
each instance uses a nice chunk of memory.

Andrea, is there a later version of aa that I could test?

Martin


                STOCK KERNEL    MH KERNEL       STOCK + SWAP    MH + SWAP       RMAP 10c        RC2AA2
                (no swap)       (no swap)                                       (no swap)       (no swap)

CLEAN
BUILD   real    7m19.428s       7m19.546s       7m26.852s       7m26.256s       7m46.760s       7m17.698s
        user    12m53.640s      12m50.550s      12m53.740s      12m47.110s      13m2.420s       12m33.440s
        sys     0m47.890s       0m54.960s       0m58.810s       1m1.090s        1m7.890s        0m53.790s
                                                1.1M swp        0M swp

CACHE
BUILD   real    7m3.823s        7m3.520s        7m4.040s        7m4.266s        7m16.386s       7m3.209s
        user    12m47.710s      12m49.110s      12m47.640s      12m40.120s      12m56.390s      12m46.200s
        sys     0m46.660s       0m46.270s       0m47.480s       0m51.440s       0m55.200s       0m46.450s
                                                1.1M swp        0M swp

SETI 1
        real    9m51.652s       9m50.601s       9m53.153s       9m53.668s       10m8.933s       9m51.954s
        user    13m5.250s       13m4.420s       13m5.040s       13m4.470s       13m16.040s      13m19.310s
        sys     0m49.020s       0m50.460s       0m51.190s       0m50.580s       1m1.080s        0m51.800s
                                                1.1M swp        0M swp

SETI 2
        real    13m9.730s       13m7.719s       13m4.279s       13m4.768s       OOM KILLED      13m13.181s
        user    13m16.810s      13m15.150s      13m15.950s      13m13.400s      kdeinit         13m0.640s
        sys     0m50.880s       0m50.460s       0m50.930s       0m52.520s                       0m48.840s
                                                5.8M swp        1.9M swp

SETI 3
        real    15m49.331s      15m41.264s      15m40.828s      15m45.551s      NA              15m52.202s
        user    13m22.150s      13m21.560s      13m14.390s      13m20.790s                      13m21.650s
        sys     0m49.250s       0m49.910s       0m49.850s       0m50.910s                       0m52.410s
                                                16.2M swp       3.1M swp
SETI 4
        real    OOM KILLED      19m8.435s       19m5.584s       19m3.618        NA              19m24.081s
        user    kdeinit         13m24.570s      13m24.000s      13m22.520s                      13m20.140s
        sys                     0m51.430s       0m50.320s       0m51.390s                       0m52.810s
                                                18.7M swp       8.3M swp

SETI 5
        real    NA              21m35.515s      21m48.543s      22m0.240s       NA              22m10.033s
        user                    13m9.680s       13m22.030s      13m28.820s                      13m12.740s
        sys                     0m49.910s       0m50.850s       0m52.270s                       0m52.180s
                                                31.7M swp       11.3M swp

SETI 6
        real    NA              24m37.167s      25m5.244s       25m13.429s      NA              25m25.686s
        user                    13m7.650s       13m26.590s      13m32.640s                      13m21.610s
        sys                     0m51.390s       0m51.260s       0m52.790s                       0m49.590s
                                                35.3M swp       17.1M swp

SETI 7
        real    NA              28m40.446s      28m3.612s       28m12.981s      NA             VM: killing process cc1
        user                    13m16.460s      13m26.130s      13m31.520s
        sys                     0m57.940s       0m52.510s       0m53.570s
                                                38.8M swp       25.4M swp

SETI 8
        real    NA              29m31.743s      31m16.275s      32m29.534s      NA
        user                    13m37.610s      13m27.740s      13m33.630s
        sys                     1m4.450s        0m52.100s       0m54.140s
                                (NO SWAP ;)     41.5M swp       49.7M swp

Re: [2.4.17/18pre] VM and swap - it's really unusable

[José Luis Domingo López]

On Thursday, 03 January 2002, at 20:14:42 -0600,
M.H.VanLeeuwen wrote:

> Here is what I've run thus far.  I'll add nfs file copy into the mix also...
> System: SMP 466 Celeron 192M RAM, running KDE, xosview, and other minor apps.
>
I applied your little patch "vmscan.patch.2.4.17.c" to a plain 2.4.17
source tree, recompiled, and tried it. Swap usage is _much_ less than in
original 2.4.17: hardware is a Pentium166 with 64 MB RAM and 75 MB
swap, and my workload includes X 4.1.x, icewm, nightly Mozilla, several
rxvt, gkrellm, some MP3 listening via XMMS, xchat, several links web
browsers and a couple of little daemons runnig.

I have not done scientific measures on swap usage, but with your patch
it seems caches don't grow too much, and swap is usually 10-20 MB lower
than using plain 2.4.17. I have also observed in /proc/meminfo that
"Inactive:" seems to be much lower with your patch.

If someone wants more tests/numbers done/reported, just ask.

Hope this helps.

-- 
José Luis Domingo López
Linux Registered User #189436     Debian Linux Woody (P166 64 MB RAM)
 
jdomingo AT internautas DOT   org  => Spam at your own risk