Re: Performance of partial object-based rmap

[William Lee Irwin III <wli@holomorphy.com>]

On Fri, Feb 21, 2003 at 01:25:25AM -0300, Rik van Riel wrote:
> For object-based reverse mapping, the worst case is with large
> objects which are sparsely mapped many times (nonlinear vmas)
> and deeply inherited COW anonymous memory (apache w/ 300 children).

Actually few users of this care about time, only lowmem space. It
was (re)invented, after all, to save lowmem used for vma's.

The technical issues with 32-bit aren't anywhere near as difficult
to deal with as the massive amount of backlash anything targeted
at addressing 32-bit issues gets. These extremely irritating attempts
to marginalize every line of code written to address 32-bit issues are
probably best dealt with by showing common benefits with the so-called
"desktop" machines and/or workloads.

So witness a 768MB, 600MHz Athlon, running xmms, xterms, and mozilla:

Mem:   767376k av,  761932k used,    5444k free,       0k shrd,   70044k buff
       619264k active,             104160k inactive
Swap:  506008k av,  155860k used,  350148k free                  197644k cached

pte_chain                    5182K          5188K      99.88%   
radix_tree_node              1338K          3088K      43.32%   
dentry_cache                 1591K          2970K      53.59%   
reiser_inode_cache            480K          1226K      39.17%   
buffer_head                  1040K          1043K      99.79%   
size-4096                     828K           828K     100.00%   
size-32                       796K           800K      99.54%   
biovec-BIO_MAX_PAGES          768K           780K      98.46%   
pgd                           704K           704K     100.00%   

nr_page_table_pages                  689

which amounts to 2756KB RAM used for PTE's, demonstrating large
amounts of internal fragmentation within the pte_chain slab.

Reducing kernel memory consumption would reduce swapping requirements,
which generally speeds things up on the precious "desktop". The vfs
should probably get its act together too, since normal usage regularly
triggers explosive dentry_cache and reiser_inode_cache space usage.

-- wli