[lkml]   [2004]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.5-rc1-aa1
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

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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:01    [W:0.115 / U:1.644 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site