pre2 swap_out() changes

pre2 swap_out() changes

[Marcelo Tosatti]

Hi Linus,

While looking at pre2 VM changes, I've saw this thing:

static int swap_out(unsigned int priority, int gfp_mask)
{
        int counter;
        int retval = 0;
        struct mm_struct *mm = current->mm;

        /* Always start by trying to penalize the process that is 
	allocating memory */
        if (mm)
                retval = swap_out_mm(mm, swap_amount(mm));


Since no process calls swap_out() directly, I dont see any sense on the
comment above. 

Is this really bogus or you're planning something? 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Linus Torvalds]

On Thu, 11 Jan 2001, Marcelo Tosatti wrote:
> 
> Since no process calls swap_out() directly, I dont see any sense on the
> comment above. 

Stage #2 is to allow them to call refill_inactive() in the low-memory case
(right now processes can only do "page_launder()" in alloc_pages(), and I
think that is wrong - it means that the only one scanning page tables etc
is kswapd)

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Zlatko Calusic]

Linus Torvalds <torvalds@transmeta.com> writes:

> On Thu, 11 Jan 2001, Marcelo Tosatti wrote:
> > 
> > Since no process calls swap_out() directly, I dont see any sense on the
> > comment above. 
> 
> Stage #2 is to allow them to call refill_inactive() in the low-memory case
> (right now processes can only do "page_launder()" in alloc_pages(), and I
> think that is wrong - it means that the only one scanning page tables etc
> is kswapd)
> 

Performance of 2.4.0-pre2 is terrible as it is now. There is a big
performance drop from 2.4.0. Simple test (that is not excessively
swapping, I remind) shows this:

2.2.17     -> make -j32  392.49s user 47.87s system 168% cpu 4:21.13 total
2.4.0      -> make -j32  389.59s user 31.29s system 182% cpu 3:50.24 total
2.4.0-pre2 -> make -j32  393.32s user 138.20s system 129% cpu 6:51.82 total

-- 
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Linus Torvalds]

On 12 Jan 2001, Zlatko Calusic wrote:
> 
> Performance of 2.4.0-pre2 is terrible as it is now. There is a big
> performance drop from 2.4.0. Simple test (that is not excessively
> swapping, I remind) shows this:
> 
> 2.2.17     -> make -j32  392.49s user 47.87s system 168% cpu 4:21.13 total
> 2.4.0      -> make -j32  389.59s user 31.29s system 182% cpu 3:50.24 total
> 2.4.0-pre2 -> make -j32  393.32s user 138.20s system 129% cpu 6:51.82 total

Marcelo's patch (which is basically the pre2 mm changes - the other was
the syntactic change of making "swap_cnt" be an argument to swap_out_mm()
rather than being a per-mm thing) will improve feel for stuff that doesn't
want to swap out - VM scanning is basically handled exclusively by kswapd,
and it only triggers under low-mem circumstances.

That's an effect of replacing "wakeup_kswapd(1)" with shrinking the inode
and dentry caches and page_launder(), and it is probably the nicest kernel
for stuff that wants to avoid caching stuff excessively. But it does mean
that we don't try to swap stuff out very much, and it also means that we
end up shrinking the directory cache in particular more aggressively than
before. Which is bad.

I really think that that page_launder() should be a "try_to_free_page()"
instead.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Marcelo Tosatti]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> That's an effect of replacing "wakeup_kswapd(1)" with shrinking the inode
> and dentry caches and page_launder(), and it is probably the nicest kernel
> for stuff that wants to avoid caching stuff excessively. But it does mean
> that we don't try to swap stuff out very much, and it also means that we
> end up shrinking the directory cache in particular more aggressively than
> before. Which is bad.
> 
> I really think that that page_launder() should be a "try_to_free_page()"
> instead.

Linus,

do_try_to_free_pages() will shrink the caches too, so I'm not sure if that
is the reason for the slowdown Zlatko is seeing. 

I dont understand the following changes you've done to try_to_swapout() in
pre2 (as someone previously commented on this thread): 

-   onlist = PageActive(page);
    /* Don't look at this pte if it's been accessed recently. */
    if (ptep_test_and_clear_young(page_table)) {
-       age_page_up(page);
-       goto out_failed;
+       page->age += PAGE_AGE_ADV;
+       if (page->age > PAGE_AGE_MAX)
+           page->age = PAGE_AGE_MAX;
+       return;
    }
-   if (!onlist)
-       /* The page is still mapped, so it can't be freeable... */
-       age_page_down_ageonly(page);
-
-   /*
-    * If the page is in active use by us, or if the page
-    * is in active use by others, don't unmap it or
-    * (worse) start unneeded IO.
-    */
-   if (page->age > 0)
-       goto out_failed;


First, age_page_up() will move the page to the active list if it was not
active before and your change simply increases the page age.

Secondly, you removed the "(page->age > 0)" check which is obviously
correct to me (we don't want to unmap the page if it does not have age 0)

The third thing is that we dont age down pages anymore. (ok, the
"onlist" thing was wrong, but anyway...)

The patch I posted previously to add background pte scanning changed this
stuff. 

Zlatko, could you try
http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.1pre2/bg_cond_pte_aging.patch
and report results?

Thanks


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Linus Torvalds]

On Fri, 12 Jan 2001, Marcelo Tosatti wrote:
> > 
> > I really think that that page_launder() should be a "try_to_free_page()"
> > instead.
> 
> Linus,
> 
> do_try_to_free_pages() will shrink the caches too, so I'm not sure if that
> is the reason for the slowdown Zlatko is seeing. 

The point is that do_try_to_free_pages() will _also_ cause some VM swapout
activity, which will cause _future_ out-of-memory behaviour to be less of
a problem (because in the future we can depend on page_launder() instead
of having to flush caches).

> I dont understand the following changes you've done to try_to_swapout() in
> pre2 (as someone previously commented on this thread): 

I removed the extra aging, because basically it was a hack to avoid
swapping out stuff that shouldn't be swapped out.

> Secondly, you removed the "(page->age > 0)" check which is obviously
> correct to me (we don't want to unmap the page if it does not have age 0)

It's NOT "obviously correct". In fact, it's obviously _not_ correct. The
fact that the _page_ is new, does not mean that the page table reference
to that page is new. We _should_ drop the page from the page tables:
because that will mean that we will be better able to handle it in
page_launder().

If the page truly is new (because of some other user), then page_launder()
won't drop it, and it doesn't matter. But dropping it from the VM means
that the list handling can work right, and that the page will be aged (and
thrown out) at the same rate as other pages.

Now, I did find one bug: we should say

	if (!page->age)
		deactivate_page(page);

because we should not deactivate the page if it has an age (but we SHOULD
throw it out of the page tables).

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Marcelo Tosatti]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> If the page truly is new (because of some other user), then page_launder()
> won't drop it, and it doesn't matter. But dropping it from the VM means
> that the list handling can work right, and that the page will be aged (and
> thrown out) at the same rate as other pages.

What about the amount of faults this potentially causes? 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Linus Torvalds]

On Fri, 12 Jan 2001, Marcelo Tosatti wrote:
> 
> On Fri, 12 Jan 2001, Linus Torvalds wrote:
> 
> > If the page truly is new (because of some other user), then page_launder()
> > won't drop it, and it doesn't matter. But dropping it from the VM means
> > that the list handling can work right, and that the page will be aged (and
> > thrown out) at the same rate as other pages.
> 
> What about the amount of faults this potentially causes? 

It only increases the number of faults on low-memory machines where the VM
has been found to be one cause of mm pressure (otherwise we never get
here: if page_launder() is able to relieve the memory pressure we'll never
even try to swap anything out).

Basically, it increases the number of soft pagefaults (the ones where we
can find the thing in the page cache) only, and only under the one
circumstance when that soft page-fault itself is going to give us more
information about page usage (ie it will help pinpoint the processes with
big memory footprints - and can make us able to slow those down in favour
of the well-behaved applications).

So I consider it to be potentially a win, not a loss. We'll see.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Rik van Riel]

On Fri, 12 Jan 2001, Marcelo Tosatti wrote:
> On Fri, 12 Jan 2001, Linus Torvalds wrote:
>
> > If the page truly is new (because of some other user), then page_launder()
> > won't drop it, and it doesn't matter. But dropping it from the VM means
> > that the list handling can work right, and that the page will be aged (and
> > thrown out) at the same rate as other pages.
>
> What about the amount of faults this potentially causes?

The change has 2 influences on the number of faults:

1. the number of soft faults should probably increase

2. refill_inactive_scan() can deactivate more pages, since
   less pages will be trapped inside processes ... this can
   lead to better page replacement and less hard page faults

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Rik van Riel]

On Fri, 12 Jan 2001, Linus Torvalds wrote:

> If the page truly is new (because of some other user), then
> page_launder() won't drop it, and it doesn't matter. But
> dropping it from the VM means that the list handling can work
> right, and that the page will be aged (and thrown out) at the
> same rate as other pages.

Presuming the page isn't shared between multiple processes.

And even then, only the *down* aging will be at the same rate
as the other pages. The *up* aging will still be at the rate
we scan the virtual memory of the processes.

_This_ is one of the main reasons I want to try the reverse
page mappings ... the sheer fact that getting the balancing
right with the current scheme is hard, if not impossible.

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Zlatko Calusic]

Marcelo Tosatti <marcelo@conectiva.com.br> writes:

> On Fri, 12 Jan 2001, Linus Torvalds wrote:
> 
> > That's an effect of replacing "wakeup_kswapd(1)" with shrinking the inode
> > and dentry caches and page_launder(), and it is probably the nicest kernel
> > for stuff that wants to avoid caching stuff excessively. But it does mean
> > that we don't try to swap stuff out very much, and it also means that we
> > end up shrinking the directory cache in particular more aggressively than
> > before. Which is bad.
> > 
> > I really think that that page_launder() should be a "try_to_free_page()"
> > instead.
> 
> Linus,
> 
> do_try_to_free_pages() will shrink the caches too, so I'm not sure if that
> is the reason for the slowdown Zlatko is seeing. 
> 
> I dont understand the following changes you've done to try_to_swapout() in
> pre2 (as someone previously commented on this thread): 
> 
> -   onlist = PageActive(page);
>     /* Don't look at this pte if it's been accessed recently. */
>     if (ptep_test_and_clear_young(page_table)) {
> -       age_page_up(page);
> -       goto out_failed;
> +       page->age += PAGE_AGE_ADV;
> +       if (page->age > PAGE_AGE_MAX)
> +           page->age = PAGE_AGE_MAX;
> +       return;
>     }
> -   if (!onlist)
> -       /* The page is still mapped, so it can't be freeable... */
> -       age_page_down_ageonly(page);
> -
> -   /*
> -    * If the page is in active use by us, or if the page
> -    * is in active use by others, don't unmap it or
> -    * (worse) start unneeded IO.
> -    */
> -   if (page->age > 0)
> -       goto out_failed;
> 
> 
> First, age_page_up() will move the page to the active list if it was not
> active before and your change simply increases the page age.
> 
> Secondly, you removed the "(page->age > 0)" check which is obviously
> correct to me (we don't want to unmap the page if it does not have age 0)
> 
> The third thing is that we dont age down pages anymore. (ok, the
> "onlist" thing was wrong, but anyway...)
> 
> The patch I posted previously to add background pte scanning changed this
> stuff. 
> 
> Zlatko, could you try
> http://bazar.conectiva.com.br/~marcelo/patches/v2.4/2.4.1pre2/bg_cond_pte_aging.patch
> and report results?
> 

2.2.17     -> make -j32  392.49s user 47.87s system 168% cpu 4:21.13 total
2.4.0      -> make -j32  389.59s user 31.29s system 182% cpu 3:50.24 total
2.4.0-pre2 -> make -j32  393.32s user 138.20s system 129% cpu 6:51.82 total
pre3-bgage -> make -j32  394.11s user 424.52s system 131% cpu 10:21.41 total

Hm, sorry to rain on your parade, but it actually made things even
worse. Notice how the system time is getting bigger with every try.

I also took an opportunity to check your swap-write-clustering patch
(you've been sending for some time to linux-kernel :)) but over the
last good performing 2.4.0 VM, but it also reduces performance and
after some testing it deadlocked.

-- 
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Rik van Riel]

On 13 Jan 2001, Zlatko Calusic wrote:

> 2.2.17     -> make -j32  392.49s user 47.87s system 168% cpu 4:21.13 total
> 2.4.0      -> make -j32  389.59s user 31.29s system 182% cpu 3:50.24 total
> 2.4.0-pre2 -> make -j32  393.32s user 138.20s system 129% cpu 6:51.82 total
> pre3-bgage -> make -j32  394.11s user 424.52s system 131% cpu 10:21.41 total

Hmmm, could you try my quick&dirty patch on
http://www.surriel.com/patches/  ?

Since I'm on linux.conf.au now, I don't have all
that much time to test these things myself, but I
have the idea this patch may be going in the right
direction.

If it is, I'll clean up more code and split up things
for Linus.

thanks,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Zlatko Calusic]

Linus Torvalds <torvalds@transmeta.com> writes:

> On 12 Jan 2001, Zlatko Calusic wrote:
> > 
> > Performance of 2.4.0-pre2 is terrible as it is now. There is a big
> > performance drop from 2.4.0. Simple test (that is not excessively
> > swapping, I remind) shows this:
> > 
> > 2.2.17     -> make -j32  392.49s user 47.87s system 168% cpu 4:21.13 total
> > 2.4.0      -> make -j32  389.59s user 31.29s system 182% cpu 3:50.24 total
> > 2.4.0-pre2 -> make -j32  393.32s user 138.20s system 129% cpu 6:51.82 total
> 
> Marcelo's patch (which is basically the pre2 mm changes - the other was
> the syntactic change of making "swap_cnt" be an argument to swap_out_mm()
> rather than being a per-mm thing) will improve feel for stuff that doesn't
> want to swap out - VM scanning is basically handled exclusively by kswapd,
> and it only triggers under low-mem circumstances.
> 

Hm, what I noticed is completely the opposite. pre2 seems a little bit
reluctant to swap out, and when it does it looks like it picks wrong
pages. During the compile sessions (results above) pre2 had long
periods where it just tried to get its working set in memory and
during that time all 32 processes were on hold. Thus only 129% CPU
usage and much longer total time.

On the other hand, 2.4.0 + Marcelo kept both processors busy at all
times. Sometimes only few processes were TASK_RUNNING, but the system
_never_ got in the situation where it had spare unused CPU cycles.

If I start typical make -j2 compile my %CPU time is also 182% or 183%,
so 2.4.0 was _really_ good.
-- 
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Marcelo Tosatti]

On 13 Jan 2001, Zlatko Calusic wrote:

> Hm, what I noticed is completely the opposite. pre2 seems a little bit
> reluctant to swap out, and when it does it looks like it picks wrong
> pages. During the compile sessions (results above) pre2 had long
> periods where it just tried to get its working set in memory and
> during that time all 32 processes were on hold. Thus only 129% CPU
> usage and much longer total time.
> 
> On the other hand, 2.4.0 + Marcelo kept both processors busy at all
> times. Sometimes only few processes were TASK_RUNNING, but the system
> _never_ got in the situation where it had spare unused CPU cycles.
> 
> If I start typical make -j2 compile my %CPU time is also 182% or 183%,
> so 2.4.0 was _really_ good.

Linus,

It seems that one of the reasons for the performance slowdown in pre2 is
that we allow too many dirty buffers in memory (now we have a lot of
processes generating dirty buffers from page_launder()).

Another problem with pre2 is that we do reclaim the slab caches *if* we
are under free memory shortage. Your "horribly bogus, danger" comment on a
previous email was right, unfortunately.

The problem is that buffer_head's are in slab cache (bh_cachep) and we
need those buffer_head's to free memory (swapout and sync).

As usual, the patch. (it also changes some other things which we discussed
previously)

Comments?

diff -Nur --exclude-from=exclude linux.orig/fs/buffer.c linux/fs/buffer.c
--- linux.orig/fs/buffer.c	Sat Jan 13 19:19:00 2001
+++ linux/fs/buffer.c	Sat Jan 13 21:20:40 2001
@@ -2406,11 +2406,13 @@
 	spin_unlock(&lru_list_lock);
 	if (wait) {
 		sync_page_buffers(bh, wait);
+
 		/* We waited synchronously, so we can free the buffers. */
 		if (wait > 1 && !loop) {
 			loop = 1;
 			goto cleaned_buffers_try_again;
 		}
+		wakeup_bdflush(0);
 	}
 	return 0;
 }
@@ -2713,7 +2715,7 @@
 		CHECK_EMERGENCY_SYNC
 
 		flushed = flush_dirty_buffers(0);
-		if (free_shortage())
+		if (free_shortage()) 
 			flushed += page_launder(GFP_KERNEL, 0);
 
 		/*
diff -Nur --exclude-from=exclude linux.orig/mm/page_alloc.c linux/mm/page_alloc.c
--- linux.orig/mm/page_alloc.c	Sat Jan 13 19:19:04 2001
+++ linux/mm/page_alloc.c	Sat Jan 13 21:19:30 2001
@@ -452,11 +452,11 @@
 		 * 	  the inactive clean list. (done by page_launder)
 		 */
 		if (gfp_mask & __GFP_WAIT) {
-			shrink_icache_memory(6, gfp_mask);
-			shrink_dcache_memory(6, gfp_mask);
-			kmem_cache_reap(gfp_mask);
+			memory_pressure++;
 
-			page_launder(gfp_mask, 1);
+			try_to_free_pages(gfp_mask);
+
+			wakeup_bdflush(0);
 
 			if (!order)
 				goto try_again;
diff -Nur --exclude-from=exclude linux.orig/mm/vmscan.c linux/mm/vmscan.c
--- linux.orig/mm/vmscan.c	Sat Jan 13 19:19:04 2001
+++ linux/mm/vmscan.c	Sat Jan 13 21:22:29 2001
@@ -74,7 +74,8 @@
 drop_pte:
 		UnlockPage(page);
 		mm->rss--;
-		deactivate_page(page);
+		if (!page->age)
+			deactivate_page(page);
 		page_cache_release(page);
 		return;
 	}
@@ -262,9 +263,9 @@
 #define SWAP_SHIFT 5
 #define SWAP_MIN 8
 
-static inline int swap_amount(struct mm_struct *mm)
+static inline int swap_amount(struct mm_struct *mm, int dec)
 {
-	int nr = mm->rss >> SWAP_SHIFT;
+	int nr = (mm->rss >> SWAP_SHIFT) / (atomic_read(&mm->mm_users) - dec);
 	return nr < SWAP_MIN ? SWAP_MIN : nr;
 }
 
@@ -274,10 +275,6 @@
 	int retval = 0;
 	struct mm_struct *mm = current->mm;
 
-	/* Always start by trying to penalize the process that is allocating memory */
-	if (mm)
-		retval = swap_out_mm(mm, swap_amount(mm));
-
 	/* Then, look at the other mm's */
 	counter = mmlist_nr >> priority;
 	do {
@@ -298,7 +295,7 @@
 		spin_unlock(&mmlist_lock);
 
 		/* Walk about 6% of the address space each time */
-		retval |= swap_out_mm(mm, swap_amount(mm));
+		retval |= swap_out_mm(mm, swap_amount(mm, 1));
 		mmput(mm);
 	} while (--counter >= 0);
 	return retval;
@@ -491,7 +488,7 @@
 
 			result = writepage(page);
 			page_cache_release(page);
-
+			
 			/* And re-start the thing.. */
 			spin_lock(&pagemap_lru_lock);
 			if (result != 1)
@@ -851,6 +848,7 @@
 	if (free_shortage()) {
 		shrink_dcache_memory(DEF_PRIORITY, gfp_mask);
 		shrink_icache_memory(DEF_PRIORITY, gfp_mask);
+	} else {	
 		kmem_cache_reap(gfp_mask);
 	} 
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Linus Torvalds]

On Sun, 14 Jan 2001, Marcelo Tosatti wrote:
> 
> As usual, the patch. (it also changes some other things which we discussed
> previously)

Have you tested with big VM's where the memory pressure is due to the VM?

We definitely need a feedback loop to dampen big-VM-footprint stuff. I
hate what you did to "swap_out()" - you removed the dampener, and you also
made it care about mm_users which I find totally non-intuitive.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Marcelo Tosatti]

On Sat, 13 Jan 2001, Linus Torvalds wrote:
> 
> On Sun, 14 Jan 2001, Marcelo Tosatti wrote:
> > 
> > As usual, the patch. (it also changes some other things which we discussed
> > previously)
> 
> Have you tested with big VM's where the memory pressure is due to the VM?
> We definitely need a feedback loop to dampen big-VM-footprint stuff. 

No, but I can imagine. I'll take a look into the feedback loop thing
Monday.






--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Ed Tomlinson]

Hi,

A couple of observations on the pre2/pre3 vm.  It seems to start swapping out 
very quicky but this does not seem to hurt.  Once there is memory preasure 
and swapin starts cpu utilization drops thru the roof - kernel compiles are 
only able to drive the system at 10-20% (UP instead of 95-100%).  Once the 
system stops swapping (in) there are some side effects.  Closing windows 
in X becomes jerky (ie you see blocks get cleared and refreshed).  If little 
or no swapping has occured X is much faster.

With the patch marcelo posted last night things change.  Now It can use cpu 
when swapping.  It does seem to start swaping (in and out) faster but the 
system remains more interactive than above.  I still see the X effect though.

Over all I think 2.4.0+marcelo's first patch(es) was fastest.

Ed Tomlinson
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Marcelo Tosatti]

On Sun, 14 Jan 2001, Ed Tomlinson wrote:

> Hi,
> 
> A couple of observations on the pre2/pre3 vm.  It seems to start swapping out 
> very quicky but this does not seem to hurt.  Once there is memory preasure 
> and swapin starts cpu utilization drops thru the roof - kernel compiles are 
> only able to drive the system at 10-20% (UP instead of 95-100%).  Once the 
> system stops swapping (in) there are some side effects.  Closing windows 
> in X becomes jerky (ie you see blocks get cleared and refreshed).  If little 
> or no swapping has occured X is much faster.
> 
> With the patch marcelo posted last night things change.  Now It can use cpu 
> when swapping.  It does seem to start swaping (in and out) faster but the 
> system remains more interactive than above.  I still see the X effect though.
> 
> Over all I think 2.4.0+marcelo's first patch(es) was fastest.

There is still a critical thing to be fixed which is the swapout selection
path (which is probably what is causing your problem in X)

Anyway, thanks for the report.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Zlatko Calusic]

Marcelo Tosatti <marcelo@conectiva.com.br> writes:

> On Sun, 14 Jan 2001, Ed Tomlinson wrote:
> 
> > Hi,
> > 
> > A couple of observations on the pre2/pre3 vm.  It seems to start swapping out 
> > very quicky but this does not seem to hurt.  Once there is memory preasure 
> > and swapin starts cpu utilization drops thru the roof - kernel compiles are 
> > only able to drive the system at 10-20% (UP instead of 95-100%).  Once the 
> > system stops swapping (in) there are some side effects.  Closing windows 
> > in X becomes jerky (ie you see blocks get cleared and refreshed).  If little 
> > or no swapping has occured X is much faster.
> > 
> > With the patch marcelo posted last night things change.  Now It can use cpu 
> > when swapping.  It does seem to start swaping (in and out) faster but the 
> > system remains more interactive than above.  I still see the X effect though.
> > 
> > Over all I think 2.4.0+marcelo's first patch(es) was fastest.
> 

My opinion exactly, Ed! Don't let me copy/paste all of your comment as
mine just beacuse your English is better. :)

> There is still a critical thing to be fixed which is the swapout selection
> path (which is probably what is causing your problem in X)
> 

Yes, while swapout code in pre3 is much cleaner and nicer to see, but
it has problems with deciding what to swap out, and streaming it all
well. Glad we agree. Will check your new patch now, to see if it helps.
-- 
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Zlatko Calusic]

Zlatko Calusic <zlatko@iskon.hr> writes:

> Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> 
> > On Sun, 14 Jan 2001, Ed Tomlinson wrote:
> > 
> > > Hi,
> > > 
> > > A couple of observations on the pre2/pre3 vm.  It seems to start swapping out 
> > > very quicky but this does not seem to hurt.  Once there is memory preasure 
> > > and swapin starts cpu utilization drops thru the roof - kernel compiles are 
> > > only able to drive the system at 10-20% (UP instead of 95-100%).  Once the 
> > > system stops swapping (in) there are some side effects.  Closing windows 
> > > in X becomes jerky (ie you see blocks get cleared and refreshed).  If little 
> > > or no swapping has occured X is much faster.
> > > 
> > > With the patch marcelo posted last night things change.  Now It can use cpu 
> > > when swapping.  It does seem to start swaping (in and out) faster but the 
> > > system remains more interactive than above.  I still see the X effect though.
> > > 
> > > Over all I think 2.4.0+marcelo's first patch(es) was fastest.
> > 
> 
> My opinion exactly, Ed! Don't let me copy/paste all of your comment as
> mine just beacuse your English is better. :)
> 
> > There is still a critical thing to be fixed which is the swapout selection
> > path (which is probably what is causing your problem in X)
> > 
> 
> Yes, while swapout code in pre3 is much cleaner and nicer to see, but
> it has problems with deciding what to swap out, and streaming it all
> well. Glad we agree. Will check your new patch now, to see if it helps.

With your last patch applied:

Kernel compilation is back to normal, under 4 minutes! Very good!

Memory hogger's behaviour haven't changed at all, for that problem to
solve we will need some major changes in the swap_out() and functions
it calls, I'm afraid.
-- 
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Rik van Riel]

On 14 Jan 2001, Zlatko Calusic wrote:

> Memory hogger's behaviour haven't changed at all, for that
> problem to solve we will need some major changes in the
> swap_out() and functions it calls, I'm afraid.

RSS limits for single big memory hogs?

(I'll clean up the patch and send it)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Rik van Riel]

On Sun, 14 Jan 2001, Ed Tomlinson wrote:

> A couple of observations on the pre2/pre3 vm.  It seems to start
> swapping out very quicky but this does not seem to hurt.  Once
> there is memory preasure and swapin starts cpu utilization drops
> thru the roof - kernel compiles are only able to drive the
> system at 10-20% (UP instead of 95-100%).

Page_launder() and refill_inactive() need to be tuned so
they function well when multiple threads are calling them.

I have been working on this (independently, no internet for
a week) and have some stuff working. I will clean it up and
will try to fix the performance problems people are seeing
now.

(and I will make sure people know the reasoning behind my patch
so nobody will change things on a whim in the future ... I'd like
2.4 to remain stable)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Rik van Riel]

On Sun, 14 Jan 2001, Marcelo Tosatti wrote:

> No, but I can imagine.

Please save imagination for the 2.5 kernel. 2.4.0 is
reasonably fine and nobody wants to repeat 2.2...

If you have a hunch something might help, but don't
understand why, then you probably shouldn't put it in
2.4.

(OTOH, if you can exactly explain why something is b0rked
in 2.4 and how to fix it and people agree with you, then
it should be something that can be safely applied after a
few days of stress-testing)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: pre2 swap_out() changes

[Benjamin Redelings I]

Does this make sensee,specially, the last two lines?
	Maybe 2.4.1-pre3 will shed some light, but I see that Marcelo basically
reverted this in his patch this morning...

-	onlist = PageActive(page);
 	/* Don't look at this pte if it's been accessed recently. */
 	if (ptep_test_and_clear_young(page_table)) {
-		age_page_up(page);
-		goto out_failed;
+		page->age += PAGE_AGE_ADV;
+		if (page->age > PAGE_AGE_MAX)
+			page->age = PAGE_AGE_MAX;
+		return;
 	}
-	if (!onlist)
-		/* The page is still mapped, so it can't be freeable... */
-		age_page_down_ageonly(page);
-
-	/*
-	 * If the page is in active use by us, or if the page
-	 * is in active use by others, don't unmap it or
-	 * (worse) start unneeded IO.
-	 */
-	if (page->age > 0)
-		goto out_failed;

-BenRI
-- 
q
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/