Re: [PATCH] (2/2) reverse mappings for current 2.5.23 VM

Re: [PATCH] (2/2) reverse mappings for current 2.5.23 VM

[Craig Kulesa]

On Wed, 19 Jun 2002, Daniel Phillips wrote:

> You might conclude from the above that the lru+rmap is superior to 
> aging+rmap: while they show the same wall-clock time, lru+rmap consumes 
> considerably less disk bandwidth.  

I wouldn't draw _any_ conclusions about either patch yet, because as you 
said, it's only one type of load.  And it was a single tick in vmstat 
where page_launder() was aggressive that made the difference between the 
two.  In a different test, where I had actually *used* more of the 
application pages instead of simply closing most of the applications 
(save one, the memory hog), the results are likely to have been very 
different.  

I think that Rik's right: this simply points out that page_launder(), at 
least in its interaction with 2.5, needs some tuning.  I think both 
approaches look very promising, but each for different reasons.  

-Craig

--
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: [PATCH] (2/2) reverse mappings for current 2.5.23 VM

[Daniel Phillips]

On Wednesday 19 June 2002 22:09, Craig Kulesa wrote:
> I wouldn't draw _any_ conclusions about either patch yet, because as you 
> said, it's only one type of load.  And it was a single tick in vmstat 
> where page_launder() was aggressive that made the difference between the 
> two.  In a different test, where I had actually *used* more of the 
> application pages instead of simply closing most of the applications 
> (save one, the memory hog), the results are likely to have been very 
> different.  
> 
> I think that Rik's right: this simply points out that page_launder(), at 
> least in its interaction with 2.5, needs some tuning.  I think both 
> approaches look very promising, but each for different reasons.  

Indeed.

One reason for being interested in a lot more numbers and a variety of loads 
is that there's an effect, predicted by Andea, that I'm watching for:  both 
aging+rmap and lru+rmap do swapout in random order with respect to virtual 
memory, and this should in theory cause increased seeking on swap-in.  We 
didn't see any sign of such degradation vs mainline, in fact we saw a 
significant overall speedup.  It could be we just haven't got enough data 
yet, or maybe there really is more seeking for each swap-in, but the effect 
of less swapping overall is dominant.

-- 
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: [PATCH] (2/2) reverse mappings for current 2.5.23 VM

[Craig Kulesa]

On Wed, 19 Jun 2002, Daniel Phillips wrote:

> On Wednesday 19 June 2002 13:21, Craig Kulesa wrote:
> > 2.5.22 vanilla:
>       ^^--- is this a typo?

Good eye, but no.  I was indeed comparing 2.5.22 to the 2.5.23 rmap 
patches.  I performed the same test on 2.5.23 later and its behavior is 
similar. 

-Craig

--
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: [PATCH] (2/2) reverse mappings for current 2.5.23 VM

[Daniel Phillips]

On Wednesday 19 June 2002 13:21, Craig Kulesa wrote:
> 2.5.22 vanilla:
      ^^--- is this a typo?

> Total kernel swapouts during test = 29068 kB
> Total kernel swapins during test  = 16480 kB
> Elapsed time for test: 141 seconds
> 
> 2.5.23-rmap (this patch -- "rmap-minimal"):           
> Total kernel swapouts during test = 24068 kB
> Total kernel swapins during test  =  6480 kB
> Elapsed time for test: 133 seconds
> 
> 2.5.23-rmap13b (Rik's "rmap-13b complete") :
> Total kernel swapouts during test = 40696 kB
> Total kernel swapins during test  =   380 kB
> Elapsed time for test: 133 seconds

-- 
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: [PATCH] (2/2) reverse mappings for current 2.5.23 VM

[Rik van Riel]

On Wed, 19 Jun 2002, Daniel Phillips wrote:

> > > 2.5.23-rmap (this patch -- "rmap-minimal"):
> > > Total kernel swapouts during test = 24068 kB
> > > Total kernel swapins during test  =  6480 kB
> > > Elapsed time for test: 133 seconds
> > >
> > > 2.5.23-rmap13b (Rik's "rmap-13b complete") :
> > > Total kernel swapouts during test = 40696 kB
> > > Total kernel swapins during test  =   380 kB
> > > Elapsed time for test: 133 seconds

> You might conclude from the above that the lru+rmap is superior to
> aging+rmap: while they show the same wall-clock time, lru+rmap consumes
> considerably less disk bandwidth.  Naturally, it would be premature to
> conclude this from one trial on one load.

On the contrary, aging+rmap shows a lot less swapins.

The fact that it has more swapouts than needed means
we need to fix one aspect of the thing (page_launder),
it doesn't mean we should get rid of the whole thing.

kind regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.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: [PATCH] (2/2) reverse mappings for current 2.5.23 VM

[Daniel Phillips]

On Wednesday 19 June 2002 13:58, Rik van Riel wrote:
> > 2.5.22 vanilla:
> > Total kernel swapouts during test = 29068 kB
> > Total kernel swapins during test  = 16480 kB
> > Elapsed time for test: 141 seconds
> >
> > 2.5.23-rmap (this patch -- "rmap-minimal"):
> > Total kernel swapouts during test = 24068 kB
> > Total kernel swapins during test  =  6480 kB
> > Elapsed time for test: 133 seconds
> >
> > 2.5.23-rmap13b (Rik's "rmap-13b complete") :
> > Total kernel swapouts during test = 40696 kB
> > Total kernel swapins during test  =   380 kB
> > Elapsed time for test: 133 seconds
> 
> Interesting to see that both rmap versions have the same
> performance, it would seem that swapouts are much cheaper
> than waiting for a pagefault to swap something in ...

You might conclude from the above that the lru+rmap is superior to 
aging+rmap: while they show the same wall-clock time, lru+rmap consumes 
considerably less disk bandwidth.  Naturally, it would be premature to 
conclude this from one trial on one load.

These patches need benchmarking - lots of it, and preferrably in the next few 
days.

We need to see cpu stats as well.

-- 
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: [PATCH] (2/2) reverse mappings for current 2.5.23 VM

[Rik van Riel]

On Wed, 19 Jun 2002, Craig Kulesa wrote:

> Where: 	   http://loke.as.arizona.edu/~ckulesa/kernel/rmap-vm/

Thank you. I take it as a big compliment that people are
not only interested in rmap on other kernel versions but
able to read and understand the rmap code well enough to
be able to do so ;)

> 2.5.22 vanilla:
> Total kernel swapouts during test = 29068 kB
> Total kernel swapins during test  = 16480 kB
> Elapsed time for test: 141 seconds
>
> 2.5.23-rmap (this patch -- "rmap-minimal"):
> Total kernel swapouts during test = 24068 kB
> Total kernel swapins during test  =  6480 kB
> Elapsed time for test: 133 seconds
>
> 2.5.23-rmap13b (Rik's "rmap-13b complete") :
> Total kernel swapouts during test = 40696 kB
> Total kernel swapins during test  =   380 kB
> Elapsed time for test: 133 seconds

Interesting to see that both rmap versions have the same
performance, it would seem that swapouts are much cheaper
than waiting for a pagefault to swap something in ...

> [Gotta tone down page_launder() a bit...]

... though I definately agree with your analysis here.
I hadn't expected to give a quick rmap port without any
of the VM balancing changes to give a performance edge
over the virtual scanning VM and am surprised by your
results.


> Modifications:
>
> 	- in vmscan.c: dropped swap_out_add_to_swap_cache(), integrated
> 	  its contents to rmap's add_to_swap() in swap_state.c.  This is a
> 	  more reasonable place for it anyway.
>
> 	- Dropped try_to_swap_out(), swap_out(), and all its brethren from
> 	  vmscan.c.  What a great feeling! :)
>
> 	- In vmscan.c's shrink_cache():
> 	  If a page is actively referenced and page mapping in use, move
> 	  the inactive page to the active list; alloc some swap space for
> 	  anon pages, then if we must, fall to rmap's try_to_unmap() to
> 	  swap.  Drop the max_mapped logic, since swap_out() is gone and
> 	  we don't need it.  If try_to_unmap() fails, put the page on the
> 	  active list.  These are all pieces of Rik's page_launder()
> 	  logic in his integrated rmap scheme.
>
> 	- use page_referenced() instead of TestClearPageReferenced() in
> 	  refill_inactive()

This changelog seems small enough for the code to be mergeable,
if it weren't for one last TODO item:

- pte_highmem support for -rmap


> Okay it's quick and dirty, but it seems to work pretty well in initial
> (and not yet rigorous) tests.  Like the full rmap patch for 2.5, I'll try
> to keep this patch up to date with the 2.5 and rmap trees until VM
> development switches to 2.5.

Thank you. I'm leaving for two meetings and a conference
in Canada later today, but I'll be back to work on rmap
for 2.5 from july 3rd.

kind regards,

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.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/

[PATCH] (2/2) reverse mappings for current 2.5.23 VM

[Craig Kulesa]

Where: 	   http://loke.as.arizona.edu/~ckulesa/kernel/rmap-vm/

This rather smaller patch serves a very different purpose than patch #1.  
It introduces the "minimal" rmap functionality of Rik van Riel's reverse 
mapping patches atop the current 2.5.23 classzone VM.  This quick patch 
was done on a whim at 1 AM, but it actually seems to perform pretty 
decently on my laptop.  Page eviction choice is quite good, even 
in the absence of any sort of page aging.  Using the same quick test as 
in the previous email: 

2.5.22 vanilla:
Total kernel swapouts during test = 29068 kB
Total kernel swapins during test  = 16480 kB
Elapsed time for test: 141 seconds

2.5.23-rmap (this patch -- "rmap-minimal"):           
Total kernel swapouts during test = 24068 kB
Total kernel swapins during test  =  6480 kB
Elapsed time for test: 133 seconds

2.5.23-rmap13b (Rik's "rmap-13b complete") :
Total kernel swapouts during test = 40696 kB
Total kernel swapins during test  =   380 kB
Elapsed time for test: 133 seconds

[Gotta tone down page_launder() a bit...]

Modifications:

	- in vmscan.c: dropped swap_out_add_to_swap_cache(), integrated 
	  its contents to rmap's add_to_swap() in swap_state.c.  This is a 
	  more reasonable place for it anyway. 

	- Dropped try_to_swap_out(), swap_out(), and all its brethren from 
	  vmscan.c.  What a great feeling! :)

	- In vmscan.c's shrink_cache():
	  If a page is actively referenced and page mapping in use, move 
	  the inactive page to the active list; alloc some swap space for 
	  anon pages, then if we must, fall to rmap's try_to_unmap() to 
	  swap.  Drop the max_mapped logic, since swap_out() is gone and 
	  we don't need it.  If try_to_unmap() fails, put the page on the 
	  active list.  These are all pieces of Rik's page_launder() 
	  logic in his integrated rmap scheme.  

	- use page_referenced() instead of TestClearPageReferenced() in 
	  refill_inactive()

	- compilation patches as per "complete" rmap patch #1 (previous 
	  email)

Okay it's quick and dirty, but it seems to work pretty well in initial 
(and not yet rigorous) tests.  Like the full rmap patch for 2.5, I'll try 
to keep this patch up to date with the 2.5 and rmap trees until VM 
development switches to 2.5.

Comments, patches, fixes & feedback always welcome. :)


Craig Kulesa
Steward Observatory, Univ. of Arizona


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