Re: Plain 2.4.5 VM

Re: Plain 2.4.5 VM

[Mark Hahn]

> The "easy way out" seems to be physical -> virtual
> page reverse mappings, these make it trivial to apply
> balanced pressure on all pages.

hmm, I've been wondering if one of our problems is that while
the active/inactive-clean/inactive-dirty system does well
at preserving age info, but the only place we actually
*learn* NEW information about page use is in try_to_swap_out:

	if (ptep_test_and_clear_young(pte))
		age up;
	else		
		get rid of it;

shouldn't we try to gain more information by scanning page tables
at a good rate?  we don't have to blindly get rid of every page
that isn't young (referenced since last scan) - we could base that
on age.  admittedly, more scanning would eat some additional CPU,
but then again, we currently shuffle pages among lists based on relatively
sparse PAGE_ACCESSED info.

or am I missing 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-mm.org/

Re: Plain 2.4.5 VM

[Rik van Riel]

On Wed, 30 May 2001, Mark Hahn wrote:

> 	if (ptep_test_and_clear_young(pte))
> 		age up;
> 	else		
> 		get rid of it;
> 
> shouldn't we try to gain more information by scanning page tables
> at a good rate?  we don't have to blindly get rid of every page
> that isn't young (referenced since last scan) - we could base that
> on age.  admittedly, more scanning would eat some additional CPU,
> but then again, we currently shuffle pages among lists based on relatively
> sparse PAGE_ACCESSED info.
> 
> or am I missing something?  

The "getting rid of it" above consists of 2 parts:

1) moving the page to the active list, where
   refill_inactive_scan will age it
2) the page->age will be higher if the page
   has been accessed more often

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: Plain 2.4.5 VM

[Jonathan Morton]

>The "getting rid of it" above consists of 2 parts:
>
>1) moving the page to the active list, where
>   refill_inactive_scan will age it

Ummm...  I don't see any movement of pages to the "active" list in
try_to_swap_out().  Instead, I see some very direct attempts to push the
page onto backing store by some means.  In the stock kernel, this is done
solely on the status of a single bit in the PTE, regardless of page->age or
it's position on any particular list.

IOW, all the fannying around with page->age really has very little (if any)
effect on the paging behaviour when it matters most - when memory pressure
is so intense that kswapd is looping.  That's why I put in the extra test
(and decrement) for page->age before going ahead with the swapping-out
business.

>2) the page->age will be higher if the page
>   has been accessed more often

In general, yes.  I think the numbers on that need to be adjusted a bit - I
really think page->age gets shrunk to zero far too quickly, compared to the
"effort" it takes to raise it.  I'm thinking about the best ways to adjust
that.

The first thing I'm considering is to make PAGE_AGE_START == PAGE_AGE_MAX,
to ensure that newly-allocated pages have the best chance of survival.
After all, it can take a *lot* of work to allocate a page, and we don't
want it swapped out before the process gets a chance to use it enough to
give it a decent age.

The second thing is to make age_page_down a decrement rather than a divide.
As I say above, it's looking far too easy to destroy a lot of hard-won
"age" with a few kswapd loops.  To go along with this, some playing with
the PAGE_AGE_* values would want doing.  If someone can give me a *really*
good reason why the aging down is a division operation, I'd like to hear it
- but in that case I suspect that PAGE_AGE_MAX should be lots higher.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

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

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
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+(*)
-----END GEEK CODE BLOCK-----


--
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: Plain 2.4.5 VM

[Marcelo Tosatti]

On Wed, 30 May 2001, Jonathan Morton wrote:

> >The "getting rid of it" above consists of 2 parts:
> >
> >1) moving the page to the active list, where
> >   refill_inactive_scan will age it
> 
> Ummm...  I don't see any movement of pages to the "active" list in
> try_to_swap_out().

Hum? Increasing the page age will move it to the active list (indirectly,
of course) if it is already a swap cache page.

Otherwise the page will be added to the swapcache (which means it will be
added to the active list). 

> Instead, I see some very direct attempts to push the
> page onto backing store by some means.  In the stock kernel, this is done
> solely on the status of a single bit in the PTE, regardless of page->age or
> it's position on any particular list.

Allocating swap space for a page and adding the page to the swap cache
will not add it to the backing store immediately. 

> IOW, all the fannying around with page->age really has very little (if any)
> effect on the paging behaviour when it matters most - when memory pressure
> is so intense that kswapd is looping. 

Jonathan,

kswapd should never loop in the first place.

We have to limit aging.

With the current behaviour of the kernel, _all_ tasks are aging each
others pages when memory pressure is really high (apart from kswapd
possibly looping).


--
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/