Multiqueue VM Patch OK? Does page-aging really work?

[Benjamin Redelings I <bredelin@ucla.edu>]

Hi guys - 
	I just want to remind people that dbench, bonnie, mmap2, and stuff are
only one type of way to measure the "performance" or the multiqueue
patch.  Even if these give good numbers (which they apparently don't
always), we still have major problems with the multiqueue patch, that I
think prevent it from being a candidate for 2.4.0 in its current state. 
Simply fixing the crashes is not good enough:

	Problem #1: 
	Simply untarring a large file (e.g. linux-2.4.0-test7.tar) evicts most
of the working set.  Example: I was running a few programs, including
netscape, with little swap in use.  Then I untarred a linux source tree,
and lo and behold, look at this!  44Mb swap!
telomere:~> cat free_after_untar 
             total       used       free     shared    buffers    
cached
Mem:         62872      61432       1440          0       1588     
41800
-/+ buffers/cache:      18044      44828
Swap:       128484      44044      84440

Now I have __44Mb__ of swap??  Interestingly there is about 41Mb cached.
One question I guess that needs to be asked is: is this cached data
"dirty data" in the newly created "linux/" tree , or is it "clean data"
from "linux.tar"?

Maybe the problem is that dirty data is given preference over other
data, and tyrannically takes over the cache. (But that couldn't be the
whole problem, see rest of this e-mail)

Anyway, for comparison, here is test8 after untarring a similar file
telomere:/usr/src/temp> free
             total       used       free     shared    buffers    
cached
Mem:         62944      60980       1964          0        752     
30900
-/+ buffers/cache:      29328      33616
Swap:       128484      13724     114760


	Problem #2:
	Programs that are basically unused, like (for example) an apache server
that I am running on my home computer, no longer have their RSS go down
to 4K.  Simply put, unused processes are not evicted, while data from
used processes IS evicted.

	Conclusion:
	1. Aren't BOTH these problems supposed to be solved by page aging?
Then, shouldn't the multiqueue-patched kernel do BETTER than test8? 
Apparently page-aging is not quite doing its job.  Why?
	2. With the drop_behind stuff, I'm sure the kernel will perform better,
at least with problem #1, to some extent.  However, even if the
drop_behind stuff is moved to the VMA level, I still think this is a
"special case hack".  I am not trying to be overly negative or critical
- it is just that the NEED for drop_behind this indicates that page
aging (the general solution) is not working.  Or am I missing something?

	In any case, what I am not missing is the fact that the multi-queue
patch is failing to reform the VM system in some of its most important
aspects.  I don't see how it could go into 2.4.0 in its current state.

keep up the good work!
-BenRI
-- 
"I want to be in the light, as He is in the Light,
 I want to shine like the stars in the heavens." - DC Talk, "In the
Light"
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.eu.org/Linux-MM/