Consistent page aging....

Consistent page aging....

[Eric W. Biederman]

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

> Sorry, Eric.
>
> The biggest 2.4 swapping bug is that we need to allocate swap space for a
> page to be able to age it. 

Well I guess biggest bug is a debatable title.  

> We had to be able to age pages without allocating swap space...

That sounds reasonable.  I haven't been over the aging code lately it
keeps changing.  You say this hasn't been fixed?  Looking... O.k. I
see what you are talking about.  

I don't see any technical reasons why we can't do this.  Doing it
without adding many extra special cases would require some thinking
but nothing fundamental says you can't have anonymous pages in the
active list.  You can't move mapped pages off of the active list
but this holds true anyway.

The only benefit this would bring is that after anonymous pages have
been converted to swappable pages they wouldn't start at the end of
the active_list.

I can see how this would be helpful, but unless you benchmark this
I don't see how this can as the biggest 2.4 swapping bug.

Eric
--
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: Consistent page aging....

[Marcelo Tosatti]

On 25 Jul 2001, Eric W. Biederman wrote:

> Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> 
> > Sorry, Eric.
> >
> > The biggest 2.4 swapping bug is that we need to allocate swap space for a
> > page to be able to age it. 
> 
> Well I guess biggest bug is a debatable title.  
> 
> > We had to be able to age pages without allocating swap space...
> 
> That sounds reasonable.  I haven't been over the aging code lately it
> keeps changing.  You say this hasn't been fixed?  Looking... O.k. I
> see what you are talking about.  
> 
> I don't see any technical reasons why we can't do this.  Doing it
> without adding many extra special cases would require some thinking
> but nothing fundamental says you can't have anonymous pages in the
> active list. 

Right.

> You can't move mapped pages off of the active list but this holds true
> anyway.
> 
> The only benefit this would bring is that after anonymous pages have
> been converted to swappable pages they wouldn't start at the end of
> the active_list.

Right now we have to allocate space on swap for any page which we want to
add to the active list. (so we are able to age the anon pages as other
cache pages)

> I can see how this would be helpful, but unless you benchmark this
> I don't see how this can as the biggest 2.4 swapping bug.

Its the "2xRAM swap rule" problem.

IMO having to allocate swap space to be able to do _aging_ on anonymous
pages is just nonsense.

Now doing the swap allocation at the time we're writting out swap pages
(page_launder()) makes sense for me.

Thats a 2.5 thing, of course...


--
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: Consistent page aging....

[Rik van Riel]

On Wed, 25 Jul 2001, Marcelo Tosatti wrote:
> On 25 Jul 2001, Eric W. Biederman wrote:
> > Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> >
> > > We had to be able to age pages without allocating swap space...
> >
> > I don't see any technical reasons why we can't do this.  Doing it
> > without adding many extra special cases would require some thinking
> > but nothing fundamental says you can't have anonymous pages in the
> > active list.
>
> Right.

Except that for - presumably dbench-related ? - reasons
Linus and Davem seem to be vetoeing this change.

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.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: Consistent page aging....

[Eric W. Biederman]

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

> On 25 Jul 2001, Eric W. Biederman wrote:
> 
> > Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> > 
> > > Sorry, Eric.
> > >
> > > The biggest 2.4 swapping bug is that we need to allocate swap space for a
> > > page to be able to age it. 
> > 
> > Well I guess biggest bug is a debatable title.  
> > 
> > > We had to be able to age pages without allocating swap space...
> > 
> > That sounds reasonable.  I haven't been over the aging code lately it
> > keeps changing.  You say this hasn't been fixed?  Looking... O.k. I
> > see what you are talking about.  
> > 
> > I don't see any technical reasons why we can't do this.  Doing it
> > without adding many extra special cases would require some thinking
> > but nothing fundamental says you can't have anonymous pages in the
> > active list. 
> 
> Right.

Let me clarify just a pinch.  I meant anonymous pages that have yet to
become swap cache pages.
 
> > You can't move mapped pages off of the active list but this holds true
> > anyway.
> > 
> > The only benefit this would bring is that after anonymous pages have
> > been converted to swappable pages they wouldn't start at the end of
> > the active_list.
> 
> Right now we have to allocate space on swap for any page which we want to
> add to the active list. (so we are able to age the anon pages as other
> cache pages)
> 
> > I can see how this would be helpful, but unless you benchmark this
> > I don't see how this can as the biggest 2.4 swapping bug.
> 
> Its the "2xRAM swap rule" problem.

I have trouble believing that.  We have nearly the same behavior
in 2.2.  The only intentional difference in 2.4 versus 2.2 is that 
2.2 removed pages from the swap cache when they become dirty, and 2.4
reuses the swap space.  This difference prompted Linus's message.

The "2xRAM swap rule problem", is a problem where a user uses 2.4 and
notices that they need more swap.  Since there has been publicity
that 2.4 needs more swap when swapping heavily, peoply commmonly to
jump to the conclusion that it is a known problem, and simply
complain.   That is the "2xRAM swap rule problem".

Given that a number of "2xRAM swap rule problem" reports tracked back
to having something like 90% of ram in dead swap cache pages, I know
that was one of the problems people complained about.  The classic
symptoms were:  a) swapoff locked up the system b) A large program was
started and filled most of swap.  The program ended.  The program
was restarted, and couldn't run because all of ram was now in dead
swap cache pages.

As far as actually requiring swap = 2xRAM the combination of keeping
pages in the swap cache after they are dirtied, and allocating the
swap space a little early achieves this, seems to achieve this
property, I admit.  Until I seem problem reports tracked back to this
I don't consider this at the top of my canidate list for the "2xRAM
swap rule problem".

> IMO having to allocate swap space to be able to do _aging_ on anonymous
> pages is just nonsense.

Be very clear on this because I sense some confusion.  We don't
``require'' allocation of swap space to do aging.  Allocating swap
space for aging just makes the code clean.

We do require swap allocation to remove a page from the page tables.
This is because of shared anonymous cow pages, formed by fork.  These
pages are extremely common (if generally short lived) so we don't want
them to get expensive.

> Now doing the swap allocation at the time we're writting out swap pages
> (page_launder()) makes sense for me.

We need to reserve space on the swap device before we remove the page
from the page tables.  If we cannot reserve space on the swap device
we are just wasting cpu time.

> Thats a 2.5 thing, of course...

You most be very careful in the swap path to keep from deadlocking the
system.

Eric

--
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: Consistent page aging....

[Eric W. Biederman]

Rik van Riel <riel@conectiva.com.br> writes:

> On Wed, 25 Jul 2001, Marcelo Tosatti wrote:
> > On 25 Jul 2001, Eric W. Biederman wrote:
> > > Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> > >
> > > > We had to be able to age pages without allocating swap space...
> > >
> > > I don't see any technical reasons why we can't do this.  Doing it
> > > without adding many extra special cases would require some thinking
> > > but nothing fundamental says you can't have anonymous pages in the
> > > active list.
> >
> > Right.
> 
> Except that for - presumably dbench-related ? - reasons
> Linus and Davem seem to be vetoeing this change.

Hmm.  I haven't seen a patch for it, and I haven't seen the change being
vetoed by Linus and Davem.  So I'd have to have more context to comment.

Eric
--
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: Consistent page aging....

[Rik van Riel]

On 25 Jul 2001, Eric W. Biederman wrote:
> Rik van Riel <riel@conectiva.com.br> writes:

> > Except that for - presumably dbench-related ? - reasons
> > Linus and Davem seem to be vetoeing this change.
>
> Hmm.  I haven't seen a patch for it, and I haven't seen the change being
> vetoed by Linus and Davem.  So I'd have to have more context to comment.

Me neither. Davem had "thrown away his code" so wasn't able
(or willing) to tell me exactly what he did. ;(

Rik
--
Executive summary of a recent Microsoft press release:
   "we are concerned about the GNU General Public License (GPL)"


		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.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: Consistent page aging....

[Eric W. Biederman]

Rik van Riel <riel@conectiva.com.br> writes:

> On 25 Jul 2001, Eric W. Biederman wrote:
> > Rik van Riel <riel@conectiva.com.br> writes:
> 
> > > Except that for - presumably dbench-related ? - reasons
> > > Linus and Davem seem to be vetoeing this change.
> >
> > Hmm.  I haven't seen a patch for it, and I haven't seen the change being
> > vetoed by Linus and Davem.  So I'd have to have more context to comment.
> 
> Me neither. Davem had "thrown away his code" so wasn't able
> (or willing) to tell me exactly what he did. ;(

Well there is a relatively cheap way to prototype the gains by better
aging.  Allocate swap pages in do_anonymous_page.  

That should take about 5 lines, and you can then run benchmarks to see
if the numbers improve.  The pages won't be allocated at exactly the
same space in swap but otherwise the numbers should be the same.

Though this might somehow slow down a fast path and cause problems.

Eric
--
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: Consistent page aging....

[Marcelo Tosatti]

On 25 Jul 2001, Eric W. Biederman wrote:

> Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> 
> > On 25 Jul 2001, Eric W. Biederman wrote:
> > 
> > > Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> > > 
> > > > Sorry, Eric.
> > > >
> > > > The biggest 2.4 swapping bug is that we need to allocate swap space for a
> > > > page to be able to age it. 
> > > 
> > > Well I guess biggest bug is a debatable title.  
> > > 
> > > > We had to be able to age pages without allocating swap space...
> > > 
> > > That sounds reasonable.  I haven't been over the aging code lately it
> > > keeps changing.  You say this hasn't been fixed?  Looking... O.k. I
> > > see what you are talking about.  
> > > 
> > > I don't see any technical reasons why we can't do this.  Doing it
> > > without adding many extra special cases would require some thinking
> > > but nothing fundamental says you can't have anonymous pages in the
> > > active list. 
> > 
> > Right.
> 
> Let me clarify just a pinch.  I meant anonymous pages that have yet to
> become swap cache pages.
>  
> > > You can't move mapped pages off of the active list but this holds true
> > > anyway.
> > > 
> > > The only benefit this would bring is that after anonymous pages have
> > > been converted to swappable pages they wouldn't start at the end of
> > > the active_list.
> > 
> > Right now we have to allocate space on swap for any page which we want to
> > add to the active list. (so we are able to age the anon pages as other
> > cache pages)
> > 
> > > I can see how this would be helpful, but unless you benchmark this
> > > I don't see how this can as the biggest 2.4 swapping bug.
> > 
> > Its the "2xRAM swap rule" problem.
> 
> I have trouble believing that.  We have nearly the same behavior
> in 2.2.  The only intentional difference in 2.4 versus 2.2 is that 
> 2.2 removed pages from the swap cache when they become dirty, and 2.4
> reuses the swap space.  This difference prompted Linus's message.
> 
> The "2xRAM swap rule problem", is a problem where a user uses 2.4 and
> notices that they need more swap.  Since there has been publicity
> that 2.4 needs more swap when swapping heavily, peoply commmonly to
> jump to the conclusion that it is a known problem, and simply
> complain.   That is the "2xRAM swap rule problem".
> 
> Given that a number of "2xRAM swap rule problem" reports tracked back
> to having something like 90% of ram in dead swap cache pages, I know
> that was one of the problems people complained about.  The classic
> symptoms were:  a) swapoff locked up the system b) A large program was
> started and filled most of swap.  The program ended.  The program
> was restarted, and couldn't run because all of ram was now in dead
> swap cache pages.
> 
> As far as actually requiring swap = 2xRAM the combination of keeping
> pages in the swap cache after they are dirtied, and allocating the
> swap space a little early achieves this, seems to achieve this
> property, I admit.  Until I seem problem reports tracked back to this
> I don't consider this at the top of my canidate list for the "2xRAM
> swap rule problem".
> 
> > IMO having to allocate swap space to be able to do _aging_ on anonymous
> > pages is just nonsense.
> 
> Be very clear on this because I sense some confusion.  We don't
> ``require'' allocation of swap space to do aging. 

Right now, we have to make anon pages become swap cache pages (which need
swap space allocated) to be able to age them in the LRU lists.

Sure, we do aging before by just scanning the pte's and the process of
adding a page to the swapcache is already some kind of aging. 

I'm talking about the aging in the LRU lists here. 

There is no confusion. Its the way 2.4 VM works. 

See? 

--
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: Consistent page aging....

[Eric W. Biederman]

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

> On 25 Jul 2001, Eric W. Biederman wrote:
> 
> > 
> > Be very clear on this because I sense some confusion.  We don't
> > ``require'' allocation of swap space to do aging. 
> 
> Right now, we have to make anon pages become swap cache pages (which need
> swap space allocated) to be able to age them in the LRU lists.

Nothing important in the aging algorithm on the active list requires
that the page be in the page cache.  The only immediate difference is
that the test to see if a page is busy needs to be updated to not
assume the page is in the page cache.  

> Sure, we do aging before by just scanning the pte's and the process of
> adding a page to the swapcache is already some kind of aging. 
> 
> I'm talking about the aging in the LRU lists here. 

Me to.
 
> There is no confusion. Its the way 2.4 VM works. 

It is a minor implemtation detail of the 2.4 VM not a fundamental
property.  If fundamental routines like add_to_page_cache didn't make
the assumption that a page they are being called on wasn't on an lru
list it might be straight forward to change.   But as it is you have
to be very careful to make that kind of change.

> See? 

Nope.

Eric
--
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: Consistent page aging....

[Jordi Polo]

El Jueves 26 Julio 2001 16:46, escribiste:
> Marcelo Tosatti <marcelo@conectiva.com.br> writes:
> > On 25 Jul 2001, Eric W. Biederman wrote:
> > > Be very clear on this because I sense some confusion.  We don't
> > > ``require'' allocation of swap space to do aging.
> >
> > Right now, we have to make anon pages become swap cache pages (which need
> > swap space allocated) to be able to age them in the LRU lists.
>
> Nothing important in the aging algorithm on the active list requires
> that the page be in the page cache.  The only immediate difference is
> that the test to see if a page is busy needs to be updated to not
> assume the page is in the page cache.
>
> > Sure, we do aging before by just scanning the pte's and the process of
> > adding a page to the swapcache is already some kind of aging.
> >
> > I'm talking about the aging in the LRU lists here.
>
> Me to.
>
> > There is no confusion. Its the way 2.4 VM works.
>
> It is a minor implemtation detail of the 2.4 VM not a fundamental
> property.  If fundamental routines like add_to_page_cache didn't make
> the assumption that a page they are being called on wasn't on an lru
> list it might be straight forward to change.   But as it is you have
> to be very careful to make that kind of change.
>
> > See?
>
> Nope.
>

if i undestood it :
we need the page in pagecache to be aged , so if they are anon, we have to 
give then swap. We have two effects that maybe not desirable:
1.- allocate swap space for active_list pages? makes sense?
2.- a very different way to scan anon and no anon pages.

What about (surely crazy idea) make the list anon page aware, so they make 
aging in anon and pagecache with no difference. When you move a page to 
inactive_dirty you can allocate space in swap if necesary so you avoid having 
a swap space for all that active_list pages .

easier to say that implement

--
Jordi

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