Re: per-process shared information

[Andrea Arcangeli <andrea@novell.com>]

On Fri, Oct 15, 2004 at 01:51:56PM -0400, Albert Cahalan wrote:
> Sure. That's not because of RSS. It's for TRS and DRS,
> which are supposed to be RSS-like values specific to
> text (code) and data.

And they're not RSS-like right now if you pick them from statm, the only
RSS-like variable is rss itself in 2.6 ;).

	*data = mm->total_vm - mm->shared_vm

all those are virtual, not physical. dunno about 2.4, but I doubt 2.4
would be much different, rss + shared where the only physical driven
things in 2.4 IIRC. (now only rss is left, and Hugh's patch adds
anon_rss back)

to me TRS and DRS have always been _virtual_ when I read the ps output,
obviously since DRS tends to be orders of magnitude bigger than RSS
itself ;).

> The VM size of text is TSIZ, and of data is DSIZ.
> These numbers, while useful, are not the same thing.

those should come out of statm pretty nicely.

> A user can configure top to display other columns if
> he has a box that can't handle /proc/*/statm well.
> The file will not be read if it is not needed.
> Start top, then do:
> 
> f     enters field modification screen
> o     disable VIRT
> q     disable RES
> t     disable SHR
> n     disable %MEM
> enter exits field modification screen
> W     writes a ~/.toprc file
> 
> So, what is the problem again?  :-)

that you can't get those values efficiently. Even assuming you're ok to
drop shared by disabling SHR, it wouldn't help, without a kernel API
change.

> Well, as long as it makes the users happy... I don't personally
> care, except to say that I don't care to document all sorts
> of kernel-specific variations. It gets hopelessly messy.

Yep, I believe users could be happy with Hugh's rss-anon_rss variant.