Messages in this thread | | | Subject | Re: per-process shared information | From | Albert Cahalan <> | Date | 15 Oct 2004 13:51:56 -0400 |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |