Re: Background scanning change on 2.4.6-pre1

Re: Background scanning change on 2.4.6-pre1

[Marcelo Tosatti]

(adding linux-mm to the discussion for obvious reasons) 

On Fri, 8 Jun 2001, Linus Torvalds wrote:

> 
> 
> On Fri, 8 Jun 2001, Marcelo Tosatti wrote:
> >
> > Don't you think it would be _much_ easier if we just moved _all_ mapped
> > pages to the active list ?
> 
> But they are..
> 
> Sure, there are anonymous pages, but once they get involved in the MM,
> they _will_ be swap-cached, and moved to the active list
> 
> As to putting anonymous pages on the active list, I don't see any
> advantage, 

Again, the advantage which I can see is that we don't have to "wait" until
anonymous pages get swap-cached (and I really dont think all anonymous
pages will get swapcached) to _then_ start to have a fair aging between
all pages in the system. 

> and Davem tried that once with noticeable performance
> degradation from the added locking and list manipulation.

David, 

Could you please send me that code so I can work on it and try to reduce
the performance degradation and take a look at the what it gives us ?

And remember even if we have a performance degradation by the locking and
list manipulation by adding this "feature", it may bring us a big
advantage on the fair aging thing I described above.


--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Marcelo Tosatti]

On Fri, 8 Jun 2001, David S. Miller wrote:

> 
> Marcelo Tosatti writes:
>  > > and Davem tried that once with noticeable performance
>  > > degradation from the added locking and list manipulation.
>  > 
>  > David, 
>  > 
>  > Could you please send me that code so I can work on it and try to reduce
>  > the performance degradation and take a look at the what it gives us ?
>  > 
>  > And remember even if we have a performance degradation by the locking and
>  > list manipulation by adding this "feature", it may bring us a big
>  > advantage on the fair aging thing I described above.
> 
> Please search the linux-mm archives, Stephen Tweedie posted my patches
> at some point long ago.
> 
> I deleted all my copies because that code does not deserve to live in
> my opinion, and the problem ought to be attacked from another angle.

Wow, that makes me very enthusiatic, David. :) 

How do you think the problem should be attacked, if you have any opinion
at all ? 

--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Marcelo Tosatti]

On Fri, 8 Jun 2001, Linus Torvalds wrote:

> 
> 
> On Fri, 8 Jun 2001, Marcelo Tosatti wrote:
> >
> > How do you think the problem should be attacked, if you have any opinion
> > at all ?
> 
> Let's try the "refill_inactive() also does VM scanning" approach, as that
> should make sure that we are never in the situation that we haven't taken
> the virtually mapped pages sufficiently into account for aging.

I've tried that in the past, and the behaviour I got was pages being
swapped out with little (or not any) VM pressure. 

Yes, we want fair aging. No, we dont want more pages being swapped out. 

Well, I'll take a look at this. 

--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Marcelo Tosatti]

On Fri, 8 Jun 2001, Linus Torvalds wrote:

> 
> 
> On Fri, 8 Jun 2001, Marcelo Tosatti wrote:
> >
> > I've tried that in the past, and the behaviour I got was pages being
> > swapped out with little (or not any) VM pressure.
> 
> What is "past"?
> 
> Remember: these days we don't do any IO at all inside "swap_out()", the
> _only_ thing we do is to age the VM and possibly move pages to the swap
> cache.

Yes, in the days where we did actual swapouts at page_launder(). 

> Which is really what you wanted - it's just that we delay moving anonymous
> pages to the swap-cache until we have some reason to (ie we delay it until
> we want to re-fill the inactive list).
> 
> Think of it as a simple issue of
>  - when we age pages, we should also check whether they've been dirtied by
>    being mapped, and whether the mappings have accessed them.
> 
> Put that way, I doubt you'll disagree.

I agree. 

> (Now, whether it gets the balancing _right_ is another matter altogether.
> We may have to tune the amount of pages that get looked at, both on the VM
> mapping side and on the active/inactive list sides).

> 
> We actually always used to do this, it was just that we delayed it until
> the active list scan started failing. Which may have been delaying it too
> much, causing "spikes" of activity.
> 
> Or maybe not. I'd like people to explore the balancing space more, instead
> of trying to tune specific parts of the existing balance.
> 
> > Yes, we want fair aging. No, we dont want more pages being swapped out.
> 
> Absolutely. "swap_out()" does not really swap pages out. The name is
> purely due to historical reasons. It should really be called
> "scan_process_mappings()" or similar.
> 
> The actual swap-out obviously happens in page_launder().

Yes. Now the problem is having swap space allocated with _NO_ pressure
may sound a bit weird to people. _I_ know that we're just allocating the
swap space, but not everybody does. 

--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[David S. Miller]

Marcelo Tosatti writes:
 > > and Davem tried that once with noticeable performance
 > > degradation from the added locking and list manipulation.
 > 
 > David, 
 > 
 > Could you please send me that code so I can work on it and try to reduce
 > the performance degradation and take a look at the what it gives us ?
 > 
 > And remember even if we have a performance degradation by the locking and
 > list manipulation by adding this "feature", it may bring us a big
 > advantage on the fair aging thing I described above.

Please search the linux-mm archives, Stephen Tweedie posted my patches
at some point long ago.

I deleted all my copies because that code does not deserve to live in
my opinion, and the problem ought to be attacked from another angle.

Later,
David S. Miller
davem@redhat.com
--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[David S. Miller]

Marcelo Tosatti writes:
 > How do you think the problem should be attacked, if you have any
 > opinion at all ?

All I know is that keeping track of anon areas is not the way
I would approach the problem.

Even if you get anon areas to work, they bloat up the common
case just to possibly make swapping a little big quicker.

I mean, it didn't degenerate to Solaris fork+exit latencies or
anything like that (that would be a huge challenge :-), but it did
show up quite noticably in the tests I had done at the time.

Later,
David S. Miller
davem@redhat.com
--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Linus Torvalds]

On Fri, 8 Jun 2001, Marcelo Tosatti wrote:
>
> How do you think the problem should be attacked, if you have any opinion
> at all ?

Let's try the "refill_inactive() also does VM scanning" approach, as that
should make sure that we are never in the situation that we haven't taken
the virtually mapped pages sufficiently into account for aging.

I'm making a 2.4.6-pre2 as I write this, give it a whirl. I've been
working with "mem=64M" for a change to verify that it's not obviously
broken. Compared to my 1GB setup it obviously doesn't cach the kernel
trees quite as well, but it seems to be fairly pleasant to work with
nonetheless.

(It is hard for me to judge - it's been some time since I last used a 64M
machine for any amount of time ;)

Please, try things out. We need to have a better feel for the balancing
heuristics.

		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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Linus Torvalds]

On Fri, 8 Jun 2001, Marcelo Tosatti wrote:
>
> I've tried that in the past, and the behaviour I got was pages being
> swapped out with little (or not any) VM pressure.

What is "past"?

Remember: these days we don't do any IO at all inside "swap_out()", the
_only_ thing we do is to age the VM and possibly move pages to the swap
cache.

Which is really what you wanted - it's just that we delay moving anonymous
pages to the swap-cache until we have some reason to (ie we delay it until
we want to re-fill the inactive list).

Think of it as a simple issue of
 - when we age pages, we should also check whether they've been dirtied by
   being mapped, and whether the mappings have accessed them.

Put that way, I doubt you'll disagree.

(Now, whether it gets the balancing _right_ is another matter altogether.
We may have to tune the amount of pages that get looked at, both on the VM
mapping side and on the active/inactive list sides).

We actually always used to do this, it was just that we delayed it until
the active list scan started failing. Which may have been delaying it too
much, causing "spikes" of activity.

Or maybe not. I'd like people to explore the balancing space more, instead
of trying to tune specific parts of the existing balance.

> Yes, we want fair aging. No, we dont want more pages being swapped out.

Absolutely. "swap_out()" does not really swap pages out. The name is
purely due to historical reasons. It should really be called
"scan_process_mappings()" or similar.

The actual swap-out obviously happens in page_launder().

			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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Linus Torvalds]

On Fri, 8 Jun 2001, Marcelo Tosatti wrote:
>
> Yes. Now the problem is having swap space allocated with _NO_ pressure
> may sound a bit weird to people. _I_ know that we're just allocating the
> swap space, but not everybody does.

Agreed. I would expect bug reports about "free" showing more swap, even
though nothing necessarily actually got written out to disk.

Note that we've actually already gotten many of those, this has been the
2.4.x behaviour all along. We'd just make it trigger even more easily (ie
without having to have any real pressure at all).

Hmm. Actually, the way 2.4.6-pre2 does things, "swap_out()" is only called
from "refill_inactive()", while the background scanning actually calls
into "refill_inactive_scan()" directly. So pre2 won't be adding stuff to
the swap cache unless there is _some_ kind of pressure on it (namely
"inactive_shortage()").

But it would be interesting to hear what people think of moving the
swap_out() call into refill_inactive_scan() instead of doing it outside..
However, that would further confuse the meaning of the "target" and
"maxscan" in the scanning phase.

		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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Rik van Riel]

On Fri, 8 Jun 2001, Marcelo Tosatti wrote:

> Yes, we want fair aging. No, we dont want more pages being swapped out. 
> 
> Well, I'll take a look at this. 

OK, I found a MUCH more serious issue in 2.4.6-pre1 ... this one
makes page_launder() actively work at making it impossible for the
system to fulfill the inactive_target and will make the system work
in refill_inactive() basically infinitely, doing page aging just for
the hell of it.

vmscan.c:
@@ -463,6 +458,7 @@
 
                /* Page is or was in use?  Move it to the active list. */
                if (PageReferenced(page) || page->age > 0 ||
+                               page->zone->free_pages > page->zone->pages_high ||
                                (!page->buffers && page_count(page) > 1) ||
                                page_ramdisk(page)) {
                        del_page_from_inactive_dirty_list(page);

This thing needs to go.

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://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Rik van Riel]

On Fri, 8 Jun 2001, Linus Torvalds wrote:

> But it would be interesting to hear what people think of moving the
> swap_out() call into refill_inactive_scan() instead of doing it
> outside.. However, that would further confuse the meaning of the
> "target" and "maxscan" in the scanning phase.

This would work if we had all the anonymous pages on the
active list, so we have an idea when we have had to "skip"
too many pages due to being mapped.

Doing things this way would also give us the information
we need to do some actual VM balancing...

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://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Linus Torvalds]

On Sat, 9 Jun 2001, Rik van Riel wrote:
> 
> This would work if we had all the anonymous pages on the
> active list, so we have an idea when we have had to "skip"
> too many pages due to being mapped.

Well, we already have an idea of that. Or rather - by making th ecall to
swap_out() unconditional, we never end up skipping anything at all: we
always balance all pools of memory, whether they are active, inactive, or
mapped.

Let's see how people react to -pre2 (and yes, I forgot to bump the version
number, so it claims to be -pre1 still. Don't send me any more bugreports
on that ;)

The way it is in -pre2 will at least not confuse people overmuch wrt the
"why is my machine claiming to be swapping even though it's not doing
anything and the disk light isn't on?" issue..

		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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Rik van Riel]

On Thu, 7 Jun 2001, Linus Torvalds wrote:
> On Thu, 7 Jun 2001, Marcelo Tosatti wrote:

> > time (the old code from Rik which has been replaced by this code tried to 
> > avoid that)
> 
> Now, I think the problem with the old code was that it didn't do _any_
> background page aging if "inactive" was large enough. And that really
> doesn't make all that much sense. Background page aging is needed to
> "sort" the active list, regardless of how many inactive pages there are.

I'll be posting a patch in a few minutes (against 2.4.5-acX, which
was the latest kernel available to me while on holidays with no
net access) which doesn't "roll over" the inactive dirty pages when
we scan the list.

This should make us reclaim the inactive_dirty pages in a much better
LRU order, so this whole background aging limiting stuff becomes close
to moot.

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://distro.conectiva.com/

Send all your spam to aardvark@nl.linux.org (spam digging piggy)

--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Andreas Dilger]

Marcello writes:
> Who did this change to refill_inactive_scan() in 2.4.6-pre1 ? 
> 
>         /*
>          * When we are background aging, we try to increase the page aging
>          * information in the system.
>          */
>         if (!target)
>                 maxscan = nr_active_pages >> 4;

A quick check in the l-k archives shows this was Zlatko Calusic
<zlatko.calusic@iskon.hr> who submitted the patch.  See

http://marc.theaimsgroup.com/?l=linux-kernel&m=99151955000988&w=4

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Jonathan Morton]

>> > This is going to make all pages have age 0 on an idle system after some
>> > time (the old code from Rik which has been replaced by this code tried to
>> > avoid that)
>
>There's another reason why I think the patch may be ok even without any
>added logic: not only does it simplify the code and remove a illogical
>heuristic, but there is nothing that really says that "age 0" is
>necessarily very bad.

Here's my take on it.  The point of ageing is twofold - to age down pages
that aren't in use, and to age up pages that *are* in use.  So, pages that
are in use will remain with high ages even when background scanning is
being done, and pages that aren't in use will decay to zero age.

I can't see what's wrong with that.  When we need more memory, it's a Very
Good Thing to know that most of the pages in the system haven't been
accessed in yonks - we know exactly which ones we want to throw out first.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)

The key to knowledge is not to rely on people to teach you it.

GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)


--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Andreas Dilger]

Linus writes:
> On Thu, 7 Jun 2001, Marcelo Tosatti wrote:
> > Who did this change to refill_inactive_scan() in 2.4.6-pre1 ? 
> 
> I think it was Andreas Dilger..

Definitely NOT.  I don't touch MM stuff.  I do filesystems and LVM only.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
--
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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Linus Torvalds]

Forgot one comment..

> > This is going to make all pages have age 0 on an idle system after some
> > time (the old code from Rik which has been replaced by this code tried to 
> > avoid that)

There's another reason why I think the patch may be ok even without any
added logic: not only does it simplify the code and remove a illogical
heuristic, but there is nothing that really says that "age 0" is
necessarily very bad.

We should strive to keep the active/inactive lists in LRU order anyway, so
the ordering does tell you something about how recent (and thus how
important) the page is. Also, it's certainly MUCH preferable to let pages
age down to zero, than to let pages retain a maximum age over a long time,
like the old code used to do.

If, after long periods of inactivity, we start needing fresh pages again,
it's probably actually an _advantage_ to give the new pages a higher
relative importance. Caches tend to lose their usefulness over time, and
if the old cached pages are really relevant, then the new spurt of usage
will obviously mark them young again.

And if, after the idle time, the behaviour is different, the old pages
have appropriately been aged down and won't stand in the way of a new
cache footprint.

Do you actually have regular usage that shows the age-down to be a bad
thing? 

		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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Linus Torvalds]

On Thu, 7 Jun 2001, Marcelo Tosatti wrote:
> 
> Who did this change to refill_inactive_scan() in 2.4.6-pre1 ? 

I think it was Andreas Dilger..

>         /*
>          * When we are background aging, we try to increase the page aging
>          * information in the system.
>          */
>         if (!target)
>                 maxscan = nr_active_pages >> 4;
> 
> This is going to make all pages have age 0 on an idle system after some
> time (the old code from Rik which has been replaced by this code tried to 
> avoid that)

He posted a nice explanation of how this change made behaviour noticeably
smoother, and how you could actually see the nicer balance between the
active and inactive lists using osview.

The code is not necessarily "correct", but this patch was accompanied by
useful real-life user information.

Now, I think the problem with the old code was that it didn't do _any_
background page aging if "inactive" was large enough. And that really
doesn't make all that much sense. Background page aging is needed to
"sort" the active list, regardless of how many inactive pages there are.

The decision to not do page aging should not be based on the number of
inactive pages, and I think the patch is correct in that sense.

Now, if you were to change the code to something like

	/* background scanning? */
	if (!target) {
		if (atomic_read(page_aging) <= 0)
			return 0;
		maxscan = nr_active_pages >> 4;
	}

and make the "page_aging" be something that goes up when we age stuff up
and goes down when we age it down, and does the proper balancing, THAT
would probably be ok. Then the decision to not age in the background would
be based on whether we have lots of pages getting aged up or not.

Heuristics should make sense, not be "random".

		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-mm.org/

Re: Background scanning change on 2.4.6-pre1

[Marcelo Tosatti]

On Thu, 7 Jun 2001, Linus Torvalds wrote:

> 
> Forgot one comment..
> 
> > > This is going to make all pages have age 0 on an idle system after some
> > > time (the old code from Rik which has been replaced by this code tried to 
> > > avoid that)
> 
> There's another reason why I think the patch may be ok even without any
> added logic: not only does it simplify the code and remove a illogical
> heuristic, but there is nothing that really says that "age 0" is
> necessarily very bad.
> 
> We should strive to keep the active/inactive lists in LRU order anyway, so
> the ordering does tell you something about how recent (and thus how
> important) the page is. Also, it's certainly MUCH preferable to let pages
> age down to zero, than to let pages retain a maximum age over a long time,
> like the old code used to do.
> 
> If, after long periods of inactivity, we start needing fresh pages again,
> it's probably actually an _advantage_ to give the new pages a higher
> relative importance. Caches tend to lose their usefulness over time, and
> if the old cached pages are really relevant, then the new spurt of usage
> will obviously mark them young again.
> 
> And if, after the idle time, the behaviour is different, the old pages
> have appropriately been aged down and won't stand in the way of a new
> cache footprint.
> 
> Do you actually have regular usage that shows the age-down to be a bad
> thing? 

Fill the active list of cache and wait for a while to get the inactive
list full.

When that happens and pressure begins, refill_inactive_scan() from
try_to_free_pages() will not be called because the inactive list is full
(the kernel "thinks" we dont have an inactive shortage). Well, not sure if
this is a bad thing in the end. 

--
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-mm.org/

Background scanning change on 2.4.6-pre1

[Marcelo Tosatti]

Hi Linus, 


Who did this change to refill_inactive_scan() in 2.4.6-pre1 ? 

        /*
         * When we are background aging, we try to increase the page aging
         * information in the system.
         */
        if (!target)
                maxscan = nr_active_pages >> 4;

This is going to make all pages have age 0 on an idle system after some
time (the old code from Rik which has been replaced by this code tried to 
avoid that)

Could you please explain me the reasoning behind this change ?  

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-mm.org/