Re: 2.4.8/2.4.9 VM problems

Re: 2.4.8/2.4.9 VM problems

[Benjamin Redelings I]

Daniel Phillips wrote:
> Could you please try this patch against 2.4.9 (patch -p0):
> 
> --- ../2.4.9.clean/mm/memory.c	Mon Aug 13 19:16:41 2001
> +++ ./mm/memory.c	Sun Aug 19 21:35:26 2001
> @@ -1119,6 +1119,7 @@
>  			 */
>  			return pte_same(*page_table, orig_pte) ? -1 : 1;
>  		}
> +		SetPageReferenced(page);
>  	}
>  
>  	/*
> 


Well, I tried this, and.... WOW!  Much better  [:)]
Was it really true, that swapped in pages didn't get marked as 
referenced before?  It almost felt that bad, but that seems kind of 
crazy - I don't completely understand what this fix is doing...

-BenRI
P.S. I tried this on my 64Mb PPro and a 128Mb PIII, and both felt like 
they had a lot more memory - e.g. less swapping and stuff.
-- 
"I will begin again" - U2, 'New Year's Day'
Benjamin Redelings I      <><     http://www.bol.ucla.edu/~bredelin/

--
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: 2.4.8/2.4.9 VM problems

[Rik van Riel]

On Mon, 20 Aug 2001, Benjamin Redelings I wrote:

> Was it really true, that swapped in pages didn't get marked as
> referenced before?

That's just an artifact of the use-once patch, which
only sets the referenced bit on the _second_ access
to a page.

Rik
--
IA64: a worthy successor to the i860.

		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: 2.4.8/2.4.9 VM problems

[Daniel Phillips]

On August 20, 2001 07:02 pm, Rik van Riel wrote:
> On Mon, 20 Aug 2001, Benjamin Redelings I wrote:
> 
> > Was it really true, that swapped in pages didn't get marked as
> > referenced before?
> 
> That's just an artifact of the use-once patch, which
> only sets the referenced bit on the _second_ access
> to a page.

It was an artifact of the change in lru_cache_add where all new pages start 
on the inactive queue instead of the active queue.

--
Daniel
--
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: 2.4.8/2.4.9 VM problems

[Daniel Phillips]

On August 20, 2001 06:13 pm, Benjamin Redelings I wrote:
> Daniel Phillips wrote:
> > Could you please try this patch against 2.4.9 (patch -p0):
> > 
> > --- ../2.4.9.clean/mm/memory.c	Mon Aug 13 19:16:41 2001
> > +++ ./mm/memory.c	Sun Aug 19 21:35:26 2001
> > @@ -1119,6 +1119,7 @@
> >  			 */
> >  			return pte_same(*page_table, orig_pte) ? -1 : 1;
> >  		}
> > +		SetPageReferenced(page);
> >  	}
> >  
> >  	/*
> > 
> 
> 
> Well, I tried this, and.... WOW!  Much better  [:)]
> Was it really true, that swapped in pages didn't get marked as 
> referenced before?  It almost felt that bad, but that seems kind of 
> crazy - I don't completely understand what this fix is doing...

With the use-once optimization, all pages start on the inactive queue 
instead of the active ring.  If the page doesn't get referenced before it 
gets to the other end of the inactive queue then it will be evicted and 
freed.  This means that somebody has to "rescue" each page that is actually 
used, before it gets to the end of the inactive queue.  This is implemented 
explicitly for generic_file_read and generic_file_write via the 
check_used_once function (which implements the use-once logic) and implicitly 
for buffers via the existing touch_buffer function.

There was no such rescue implemented for swap pages because when I originally 
submitted patch as an [RFC] I was doing all my testing without using any swap 
space, just file IO.  At the time, also, there other things wrong with the 
swap cache so that it was hard to see the bad effects of this omission.

Just setting the page referenced means that page_launder or reclaim_page will 
see the referenced bit and move the page to the active list, so it can live 
out its normal life cycle.

A similar thing has to be done in filemap_nopage (which will take care of 
mmap pages) and also for any filesystems whose page accesses bypass  
generic_read/write, for example, the new directory-in-pagecache code in ext2.
I'm thinking now about whether it's best to take an approach that plugs all 
the holes in a generic way, or instead just hunt them down one by one.  Once 
you know such holes are there it's not particularly hard to find and fill 
them.  It's tempting to try and move this logic to a more central place - the 
problem with that is, in the central place it's hard to filter out accesses 
that aren't real uses, such as readahead.

A final note: though the swap cache is not able to take full advantage of the 
use-once logic (because we don't have a good way of checking the state of the 
hardware page referenced bit - yet) it still does get a small benefit from 
the machinery: when we optimistically read ahead from swap, those pages that 
are not actually used will not be faulted in, thus will not have their 
referenced bit set, thus will be discarded quickly.

--
Daniel
--
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: 2.4.8/2.4.9 VM problems

[Rik van Riel]

On Mon, 20 Aug 2001, Daniel Phillips wrote:

> A similar thing has to be done in filemap_nopage (which will
> take care of mmap pages) and also for any filesystems whose page
> accesses bypass generic_read/write,

Either that, or you fix page_launder() like I explained
to you on IRC yesterday ;)

Rik
--
IA64: a worthy successor to the i860.

		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/