Re: per-process shared information

[Albert Cahalan <albert@users.sf.net>]

On Fri, 2004-10-15 at 13:13, Andrea Arcangeli wrote:
> On Fri, Oct 15, 2004 at 12:31:52PM -0400, Albert Cahalan wrote:
> > Currently, ps uses /proc/*/stat for that. The /proc/*/statm
> 
> maybe you mean /proc/pid/status, status has the RSS and most virtual
> info too, I doubt stat has it too (a trivial grep doesn't reveal it at
> least).

It's a popular value.

stat: in bytes, between vsize and rss_rlim
statm: in pages, between size and share
status:  in KiB as VmRSS

> Anyways my ps definitely reads /proc/*/statm with the 'v' option
> (confirmed by strace).

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.

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

> peraphs we use different procps version. I heard there is more than one
> version, and I know you're maintaining one but I never followed the
> details, you sure know better than me why the above is happening on my
> machine. But the point is that there are widely used apps opening statm
> (top as you mentioned), and those apps normally don't care about
> "shared" (or at least they can't underflow), and those must run on the
> big boxes too, and statm was basically unfixable.

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?  :-)

> > What exactly would be the difference, and when might users see it?
> 
> one difference for example is that it cannot take into account for
> shared anonymous pages generated by fork(). Or other corner cases would
> be posisble, but I believe it's a minor issue... so it's looking good.
> Frankly I was thinking shared as a page_mapcount > 1, while all
> pagecache is considered "shared", so Hugh's algorithm is a lot closer to
> the old shared than what I thought originally. Peraphs solaris also
> implements it as rss - anon_rss (I mean, they must be facing similar
> issues, and the report states the "shared" info is being reported with
> the same semantics on linux 2.4 and solaris and some other unix... so
> the theory Hugh's matching other unix even better than 2.4 sounds
> reasonable).

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.