Re: 2.6.5-rc1-aa1

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Mar 18, 2004 at 10:32:58AM -0500, Rik van Riel wrote:
> At that point we'll want to split the file-backed stuff off

the filebacked stuff is already separated, what can be separated further
is the preparation for the page->as.mapping support.

> I'm kind of curious which one will end up better under
> which workloads ;)

I know of big iron critical workloads where mine will work better,
though I agree for a desktop not runing kde the anonm is cheaper in
terms of memory utilization (saves .

andrea@dualathlon:~> egrep 'vm_area|anon_vma' /proc/slabinfo 
vm_area_struct      6613   8500     76   50    1 : tunables  120   60    8 : slabdata    170    170      0
anon_vma            2085   2250     12  250    1 : tunables  120   60    8 : slabdata      9      9      0
andrea@dualathlon:~> free
             total       used       free     shared    buffers     cached
Mem:       1031348    1014156      17192          0      18144     665052
-/+ buffers/cache:     330960     700388
Swap:      1028152          0    1028152
andrea@dualathlon:~> 

the anonmm would take 12*2085+6613*12 = 104k less in my 1G desktop loaded with
my usual stuff (not really, the difference is less than 100k since anonmm takes
quite some bytes, which is significant too if we count the kbytes like I'm
doing), I believe those 100k may be worth it for the super high end workload
swapping 8G on a 16G box with hundred of tasks each task with its own anonymous
direct memory big chunk of memory, anon_vma will avoid checking all hundred MM
for each anon page we swap, plus it gets mremap efficiently which sounds safer
for the short term.